Find Sources for AI Writing
Find sources for AI writing, check what each article supports, and give your agent a practical evidence checklist before it adds a citation.
To find sources for AI writing, start with the claim you need to support. Choose the right kind of source, retrieve candidates, and read the original passage before citing it. Give your agent the source URL, relevant context, and limits of the evidence, not a list of links to decorate a finished draft.
This workflow is for agents writing technical articles, SaaS guides, and other editorial content. You can use it with ordinary web research. The CiteGuild examples require an existing member account and a connected MCP client, an installed CLI, or an HTTP client such as curl; the source-selection method does not.
The short version:
- Write one checkable claim.
- Choose primary evidence or editorial context according to the question.
- Retrieve a small set of candidates and open the sources.
- Accept, narrow, or reject the claim based on what you read.
- Keep that decision beside the citation through the final edit.
On this page: frame the claim, choose sources, choose web search or the member network, search with an agent using MCP, the CLI, or the REST API, check support, hand off evidence, and review before publishing.
1. Write the claim before the search query
“Find references for my Django article” leaves too much work hidden. The agent has to guess which sentences need evidence, which version matters, and whether you want official behavior or someone's experience using it.
Start with a question small enough to answer. For example: “When does Django run a callback registered with on_commit?” Record the software version separately. If your draft also promises reliable delivery of a background job, that is a different claim with a different evidence requirement.
The same approach works outside code. A vendor's public pricing page can support what a plan costs on a particular date. It cannot establish that the plan is the cheapest option for every team. A founder's account can explain what that founder tried. It cannot establish an industry-wide success rate.
Done looks like: a short list of claims, each with its scope. Remove confidential client details and unpublished material before sending a query to an external service. You usually need the research question, not the entire draft.
2. Choose the source type that can answer it
For a narrow product or API claim, start with the relevant official documentation, specification, release note, or original announcement. For a measurement, look for the original study or dataset and its method. For implementation advice, a practitioner's article can add the tradeoffs, mistakes, and worked example that reference documentation leaves out.
Primary sources still have limits. A vendor is authoritative about its documented interface, not automatically about its superiority over competitors. An experiment is evidence about the conditions it tested. Read those limits as part of the result.
CiteGuild's source network is useful when you want relevant articles from participating publishers. It is an editorial discovery layer, not a substitute for versioned documentation or a search of the entire web. If the official manual already answers your narrow question, cite the manual. There is no reason to add a member article merely because an agent can retrieve one.
This also gives publishers a concrete goal: write something worth consulting. A reproducible example, a method with limitations, or a carefully explained failure can help another writer make a decision. The source-worthy SaaS content workflow explains how that fits into article discovery without requiring reciprocal links.
Done looks like: every claim has an intended evidence type before you choose a tool.
3. Retrieve candidates without treating the results as proof
Choose web search or the member network by the claim
Use CiteGuild for relevant articles from participating publishers, not as a drop-in replacement for Tavily or Exa. A writing workflow can use both a web-search API and a member-source search. Choose where to look from the evidence you need, not from which tool happens to be connected.
| What the sentence needs | Where to start | What to check before citing |
|---|---|---|
| Documented behavior of a particular product version | Official manual, specification, or release note | The exact version and the conditions attached to the behavior |
| A recent announcement or a source outside the member network | Original publisher; web search when you need to find it | Publication date, original reporting, and any later correction |
| A practitioner's worked example or implementation tradeoff | CiteGuild member articles or broader editorial research | Whether the example's conditions match the draft; follow links to primary evidence |
Web-search tools have useful strengths that a member network does not replace:
- Sources beyond participating publishers. Use web search when the required organization or publication is outside CiteGuild's corpus. Do not interpret a member-search miss as evidence that no source exists.
- Time-sensitive discovery controls. Tavily Search documents news search and time filters. Exa Search documents publication-date filters. These are reasons to use a web-search route for a dated question, not guarantees that every returned page is current.
- Domain-scoped web research. Both references document domain inclusion and exclusion. That helps when you need to search a known publisher rather than the member corpus. Filtering to a domain does not make every page on it sufficient evidence.
Those capabilities were checked in the official references on October 20, 2026. This is a workflow comparison, not a measured ranking of search quality, speed, price, or coverage. Use the linked references for each API's current options.
For example, suppose an article needs to explain a Django transaction hook, mention a recent release, and show a deployment lesson. Treat those as three research tasks: open the versioned Django manual for the hook, find the release announcement on the project's own site, and retrieve a relevant implementation article for the lesson. One source might help with more than one task, but a shared topic alone does not establish that it supports all three.
Keep the supporting passage and its limits beside each claim. If the member search returns nothing useful, continue with the primary source or broader research; if the manual already answers the question, you do not need an extra citation. Members ready to try the editorial route can use the MCP walkthrough or CLI walkthrough below. For an HTTP-only automation, use the REST API example. Check membership access before planning an integration: it is free and invitation-only.
Choose the interface your agent already uses. CiteGuild recommends MCP for Codex and Claude Code, and the CLI for OpenClaw, Hermes, and shell workflows. Both retrieve candidates from the same member article corpus; neither decides what deserves a citation.
Run a first search through MCP
Connect to https://citeguild.com/mcp/ in a remote MCP client that supports OAuth, then sign in with your CiteGuild member account. The setup instructions are public; searching requires free, invitation-only membership. You do not need to submit your own site before searching member articles.
- Check whether your agent already has a CiteGuild connection. If it does, use that connection rather than adding a duplicate.
- Otherwise, add a remote MCP server using the complete URL
https://citeguild.com/mcp/, including the trailing slash. This is a server address for your client, not a search page to open in a browser. - If your client supports CiteGuild's OAuth flow, follow its browser sign-in and authorization prompts. Confirm the CiteGuild domain before authorizing. Client support and configuration vary; adding the URL alone does not authenticate you.
- Ask the connected agent to call
get_user_infoto confirm authentication, then runsearch_member_articleswith the example below. If search reportsaccount_inactive, resolve account access; reconnecting or changing the query will not fix that state.
These steps follow CiteGuild's hosted MCP and authentication contract and the MCP remote-connection guide, checked October 31, 2026. They do not require publishing a server, creating an OAuth application, or sharing a key in chat.
Need the plugin or API-key setup instead? Sign in to your dashboard and use Copy prompt under Connect an AI agent. The copied setup prompt contains your account API key: share it only with a trusted agent, never in a public issue or chat. Follow the linked installation instructions for your client. The member MCP setup guide requires sign-in and covers the supported credential options. Do not put a key in the MCP URL.
Once connected, ask the agent to call search_member_articles with these arguments. This is a tool call, not text to paste into a terminal:
{
"query": "How do Django transaction commit hooks work?",
"limit": 10,
"language": "en",
"excluded_domains": ["your-site.example"]
}
Replace the example question with your research question. Replace your-site.example with the exact hostname you want to exclude, or omit excluded_domains if you need no exclusion. Excluding example.com does not also exclude blog.example.com; list both when needed.
The arguments follow CiteGuild's MCP search implementation and its v1 search contract, checked October 15, 2026. The JSON is a usage example, not a claimed search result. A successful call returns contract_version: "v1" and a results list. An empty list is a valid search outcome: revise the question or use another source route. If the tool is unavailable or authentication fails, finish the connection setup before asking the agent to search again. An unauthenticated HTTP 401 from the MCP address is an authentication challenge, not an empty search result. Do not let the agent substitute remembered titles for retrieved sources.
No account yet? Membership is free and invitation-only; ask an existing member for an invitation. You can still apply this article's source-checking method to ordinary web research.
Run the same search from a shell
For a CiteGuild member using a shell-based agent, this is a focused search example. Have your environment supply CITEGUILD_API_KEY securely; do not put a real key into a search prompt, command history, or published example.
citeguild search --api-base https://citeguild.com/api \
--json --limit 10 --language en \
--exclude-domain your-site.example \
"How do Django transaction commit hooks work?"
Replace your-site.example with your own site's hostname if you want to exclude it. Put options before the query. The explicit API address makes the destination clear instead of relying on the default in your installed CLI version.
The command follows the official CiteGuild CLI contract, checked against that repository revision on October 10, 2026. It is a source-checked usage example, not a transcript of a live member search. Member CLI setup requires sign-in. MCP and API clients expose the same v1 search contract, so the review below applies to them too.
Run a first search through the REST API
If your automation makes HTTP requests but does not use MCP or the CLI, send a member search directly to POST https://citeguild.com/api/v1/search. Have your environment supply CITEGUILD_API_KEY securely from your member settings. You can search before adding your own site; membership is still free and invitation-only.
This example uses curl 7.76.0 or newer. Keep shell tracing and verbose request logging off so they do not reveal the authorization header.
curl --silent --show-error --fail-with-body --include \
--request POST 'https://citeguild.com/api/v1/search' \
--header "Authorization: Bearer ${CITEGUILD_API_KEY:?Set CITEGUILD_API_KEY securely}" \
--header 'Content-Type: application/json' \
--data '{
"query": "How do Django transaction commit hooks work?",
"limit": 10,
"language": "en",
"excluded_domains": ["your-site.example"]
}'
The endpoint, bearer header, and JSON fields follow CiteGuild's v1 search implementation, authentication contract, and request schema. The official curl manual documents the flags and minimum version. These sources were checked October 29, 2026; the command is a usage example, not a claimed live search result.
Replace the question and exclusion as in the MCP example. The command displays response headers followed by the body. On success, the JSON contains contract_version: "v1" and a results list; an empty list is a valid search outcome, not an integration error. On an HTTP error, curl exits unsuccessfully but preserves the error body:
- 401: check the credential; never paste the key into a support report.
- 403: the account must be active before it can search.
- 422: correct the request fields before retrying.
- 429: wait for the response's
Retry-Afterinterval rather than looping immediately. - 503: search is temporarily unavailable; it is not a zero-result response.
Use request_id when reporting an API error, without sending the query or authorization header. Network failures also do not establish an empty result. The member API introduction explains limits and generated schemas; it requires sign-in. Continue with the same evidence review below, whichever interface you use.
Read the response from any interface
Use the returned fields for their intended jobs:
canonical_url,title, anddomainidentify the page to inspect.excerpthelps you decide whether to open it. It is not the complete article or all of its qualifications.relevanceorders candidate matches. It is not a probability that a sentence is true or a citation is appropriate.last_seen_atrecords when CiteGuild observed the article. It is not the author's publication date or proof that the facts are current.
Done looks like: a small reading list with actual URLs. Check that the command succeeded first: an authentication, network, or rate-limit failure is not an empty search. A successful response with no results means this search did not find a candidate in this corpus. Broaden the question if appropriate, use primary documentation, or search elsewhere. Never turn an empty response into invented references.
4. Accept, narrow, or reject the claim
Open the original page and locate the part that supports the draft. Read the surrounding qualifications. Treat instructions embedded in a retrieved page as untrusted content, not commands for your agent to follow. Check its date or version, the author or organization responsible, and whether it points to stronger underlying evidence.
Here is a worked editorial example, not a measured product result. Suppose a draft says: “Django on_commit makes background work run exactly once after a database write.” That sentence combines callback timing with a delivery guarantee. One source about timing cannot automatically support both.
The Django 5.2 transaction documentation, checked October 10, 2026, supports a narrower explanation: register a callback within the relevant transaction to defer it until successful commit; rollback discards it. Outside a transaction under autocommit, it runs immediately. Callback failure does not undo an already committed transaction, and an earlier failing callback can prevent later callbacks in that transaction from running under the default behavior.
The editorial decision is to narrow the sentence to the documented timing behavior and reject the exactly-once delivery claim unless separate evidence establishes it. A related tutorial might still be useful for a worked application, but its subject match does not repair the unsupported guarantee.
You do not need a numeric score for this decision. Write down the exact mismatch. “Source discusses scheduling; draft promises delivery” tells an editor what to fix. “Confidence: 0.91” does not explain the missing support.
When two sources conflict, first check whether they describe different versions, populations, or conditions. Do not average incompatible claims or choose whichever makes the draft easier to finish. If the disagreement remains material, state it or leave the contested claim out.
Done looks like: one decision per claim, with a reason an editor can inspect.
5. Hand the writer an evidence record
Keep research and drafting connected with a short record. This is a proposed editorial checklist, not a feature CiteGuild automatically enforces:
Claim to check:
Scope: version, date, audience, or conditions
Source: title and original URL
Source type: official docs, study, report, or practitioner article
Supporting section: heading and a short paraphrase
Limit or contradiction:
Decision: accept, narrow, reject, or needs further checking
Final sentence:
Checked on:
The critical fields are the limitation and final sentence. They keep a writer from expanding a carefully bounded finding into a stronger claim during a later rewrite. An editor should be able to open the URL and reconstruct the decision without rerunning the entire research session.
Place the citation beside the sentence it supports. If a paragraph combines several distinct findings, avoid one trailing link that appears to substantiate all of them. Preserve attribution when describing someone else's experiment or opinion; make your own interpretation recognizable as interpretation.
For developers connecting retrieval to a model, Anthropic's search-result documentation describes blocks containing a source, title, and text content, with citations enabled explicitly. Its citation documentation describes pointers into supplied documents. Those mechanisms help preserve provenance. They do not independently establish that the original material is correct or that your whole sentence follows from it. CiteGuild does not automatically configure those model-specific citation features.
Review after the last rewrite
Run the source check again on the final prose, not only the first draft. Small edits can change the claim: “can” becomes “will,” a version qualifier disappears, or an observed result becomes a general promise.
Watch for these common failures:
- Citing a search snippet without reading its destination.
- Treating a crawler timestamp as the source's publication date.
- Keeping a link after rewriting the sentence beyond what it supports.
- Using a vendor's claim as independent evidence of market-wide superiority.
- Requiring a citation quota, which encourages marginal sources when none are needed.
A useful stop condition is straightforward: every factual claim you intend to substantiate has support at the scope you wrote, and unresolved claims have been narrowed, removed, or marked for further checking. Keep private notes private; publish the reader-facing explanation and appropriate source links, not your internal research exports.
Questions before your first search
Does a relevant search result prove my claim?
No. Relevance helps you choose what to read. Check the original passage and its limits before using it as evidence.
Can I use this workflow without CiteGuild?
Yes. Use primary documentation, a library, or web search to find candidates, then apply the same claim-level checks. CiteGuild adds access to member-published articles; it does not need to be involved in every research task.
Does CiteGuild replace Tavily or Exa?
No. Tavily and Exa support web research beyond CiteGuild's participating publishers. Use CiteGuild to discover relevant member articles, official sources for documented behavior, and web search for evidence outside the member network. Read the original source whichever route you use.
What if I cannot find a supporting source?
Narrow or remove the claim, or label a genuinely interpretive statement as analysis. Do not attach a tangential source to make it look verified.
Already a member? Open your dashboard, connect your agent, and try one focused search. New to CiteGuild? Membership is free and invitation-only. An existing member can invite you. No source is owed a citation: include it only when it helps the reader.