How do I use claudette?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claudette What would Mary Parker Follett say about managers who rule by control?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

claudette

by michaelcpattinson-star

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Claudette

An assistant that answers only from texts written by women — and says so when they did not write about it.

Claudette is a corpus of thirty-six public-domain works by twenty-seven women (1694–1922), a search index over them, and an MCP server that hands passages to whatever model you already use. Every answer is built from those passages and cites them so you can check. If the women in the corpus did not write about something, Claudette tells you that, rather than filling the gap from elsewhere.

MIT licensed. The server holds no API key and makes no network call after its first run. It runs on your Claude subscription, not the author's.

Why

Most of what a large language model has read was written by men. That is not a complaint about any individual author; it is a fact about who got published, for most of the period the training data covers. And it has a flavour. The management canon in particular — from Taylor's stopwatch onward — is a literature of control: how to get more out of people who are treated as inputs.

There was always another literature. Mary Parker Follett was writing about power-with rather than power-over in 1918, while scientific management was at its height; her work was buried for fifty years and is now quietly cited by everyone who writes about collaboration. Jane Addams ran an institution on the principle that you cannot judge someone's conduct until you have understood their situation. Elizabeth Gaskell wrote the industrial novel from inside a strike and gave both sides faces. Ida Tarbell documented, from the primary sources, what a very rich man does when nobody stops him.

Claudette does not claim that women are nicer. It makes a narrower, testable claim: if you constrain an assistant's evidence to what these women wrote, and make it cite every line, you get a different and better conversation about people, work and power — and you can see exactly where each sentence came from.

Related MCP server: Quotewise MCP Server

What it is not

It is not a language model trained only on women's writing. Nobody can build that in an afternoon and anyone who says they have is selling something. Claudette's evidence is constrained; the prose is generated by a general model (Claude, by default). The guarantee is about provenance of what she tells you, not about the training data of the model that phrases it. The corpus_provenance tool says this too, in every session.

Use it as a connector (recommended)

The server speaks MCP over stdio. Add it to Claude Code:

claude mcp add claudette -- uvx --from git+https://github.com/michaelcpattinson-star/claudette claudette-mcp

Or to Claude Desktop, in claude_desktop_config.json:

{
  "mcpServers": {
    "claudette": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/michaelcpattinson-star/claudette", "claudette-mcp"]
    }
  }
}

On first run it downloads a prebuilt index (~37 MB) from the GitHub release into ~/.claudette/; if that is unavailable it fetches the 36 texts from Project Gutenberg and builds the index itself (a few minutes, once). Then ask:

What would Follett say about a manager who thinks in terms of control?

The model will call search_corpus, read the status, and answer with citations like [Mary Parker Follett, The New State §412]. Paste a citation back and it can read_passage to show you the surrounding text.

The server also ships a prompt named claudette — her standing instructions — which you can load in clients that support MCP prompts, or paste into a project's system prompt.

Hosting it for others

claudette serve --http --host 0.0.0.0 --port 8000

serves streamable HTTP at /mcp, suitable for a remote connector. Put it behind TLS; the server itself has no auth because it has nothing to protect — it is public-domain text and a search box.

Use it from the command line

uv sync --group chat            # anthropic SDK; needs credentials
uv run claudette ask "What does George Eliot say about unhistoric acts?"
uv run claudette chat            # multi-turn

ask and chat run the same loop the connector would, but with the Anthropic SDK against your own credentials (ant auth login or ANTHROPIC_API_KEY). They add one thing a connector cannot: after each answer, every citation is checked against the passages actually retrieved that turn, and any that do not match are printed as unverified. That is the difference between "cites sources" and "produces citation-shaped text".

No model is needed for the corpus itself:

uv run claudette fetch           # download from Gutenberg → ~/.claudette/texts
uv run claudette verify --show 3 # check each header matches the manifest; eyeball the openings
uv run claudette index           # build ~/.claudette/claudette.db
uv run claudette search "power over" -k 3
uv run claudette read follett-new-state§412
uv run claudette works --shelf thought

How the guarantee is enforced

There is no classifier deciding whether a text was written by a woman. There is a list — corpus/manifest.toml — and the index is built from that list and nothing else. Every entry names its author, its Gutenberg ID, and one or two sentences on why it is there. A reviewer can read the whole thing in five minutes, which is the point.

Around the list:

Validation refuses an entry without an author. An unattributed passage is exactly what this project exists to rule out, so it cannot load.
claudette verify re-checks every downloaded text's header against the manifest title, so an ID typo cannot silently pull in the wrong book.
Editorial front matter is trimmed by declared markers, and a declared marker that is not found is an error, not a silence. Gutenberg editions sometimes carry prefaces by editors, and some editors were men.
Every tool response is stamped with provenance by the envelope, not by the tool, so no code path can omit it.
no_coverage is a status, not an empty list. A model handed [] narrates it as "they had nothing to say". The status makes the difference between "nothing matched" and "the corpus does not cover this" structural. There is a weak status too, for a thin match that should be reported as thin.

The corpus is in ~/.claudette/ and is not committed: it is reproducible from the manifest by anyone with claudette fetch && claudette index.

The corpus

Twenty-seven authors, two shelves. Full list with reasons in the manifest; list_works returns it at runtime.

Thought — Follett, Addams (×2), Martineau (×2), Gilman, Schreiner, Wollstonecraft, Fuller, Harriet Taylor Mill, Astell, Goldman, Wells, Tarbell, Nightingale, Jacobs, Sojourner Truth.

Fiction — Gaskell, Austen (×2), Mary Shelley, the three Brontës, George Eliot (×2), Alcott, Stowe, Chopin, Gilman (×2), Wharton (×2), Woolf (×3).

Known limits, stated rather than hidden

Public domain means the corpus ends in 1922. It is heavily English-language and Anglo-American, and it is the canon that survived, which is its own bias.
Retrieval is BM25 over passages (SQLite FTS5, Porter stemming). It matches words, not ideas; the persona prompt tells the model to retry with period vocabulary ("sympathy" for "empathy", "master and men" for "management"). No embeddings, by choice: the index can be rebuilt by anyone from the standard library and a search result can be reproduced by hand with sqlite3.
Front-matter trimming is per-work and manual. claudette verify --show 5 exists so a reviewer can look.
The evals in evals/ exist and are wired, and have not yet been run. evals/results/README.md says so. Numbers appear when someone runs them.

Adding a work

Find it on Project Gutenberg. Confirm the author.
Add a [[work]] entry to the manifest: id, slug, author, title, year, shelf, why. Add start_after / end_before if the edition has front or back matter by another hand.
claudette fetch && claudette verify --show 5 && claudette index.
pytest. The manifest tests will tell you if the entry is malformed.
Open a pull request. The why line is the review.

Layout

src/claudette/
  data/manifest.toml   the list. Symlinked at corpus/manifest.toml for reviewers.
  manifest.py          loads and validates it
  fetch.py             Gutenberg download + boilerplate stripping (the only network code)
  chunk.py             paragraphs → citeable passages
  index.py             SQLite FTS5 build and query; the refusal rule
  envelope.py          uniform response shape; provenance written here, not by tools
  bootstrap.py         first-run: prebuilt index or local build
  server.py            the MCP server. Four tools, one prompt. No key.
  persona.py           Claudette's standing instructions
  chat.py              CLI chat client — the only module that calls a model
  cli.py               `claudette` command
tests/                 offline; builds a fixture corpus the same way as the real one
evals/                 questions, runner, mechanical scorer

Licence

MIT for the code. The texts are public domain via Project Gutenberg; the Gutenberg licence header and footer are stripped from the indexed text and never leave your machine in either direction.

Available Tools

4 tools

corpus_provenanceA

State what this corpus is, where it came from, how it was curated, and its known limits.

Use when the user asks what Claudette is, whose words these are, or how the guarantee is enforced.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`status`	Yes	ok — passages found that match most of the question's terms. weak — something matched, but thinly; say so if you use it. no_coverage — the corpus does not speak to this. Say that. Do not answer from elsewhere. not_found — a specific reference did not resolve.
`constraint`	No
`provenance`	No
`limitations`	No	Part of the answer, not a disclaimer.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It conveys that this is an informational, non-mutating tool by saying 'State what...', and it discloses the boundaries of what will be reported, including known limits. It does not discuss side effects or auth, but for a zero-parameter informational tool the description is adequately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first states the tool's job and output content, the second gives usage triggers. It is front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has zero parameters and an output schema, so the description only needs to convey purpose and invocation timing, which it does. Nothing essential is missing for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the schema places no burden on the description. The baseline of 4 applies because there is nothing for the description to annotate about parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence uses a specific verb ('State') and resource (corpus provenance) and spells out the exact content: what the corpus is, its origin, curation, and limits. This separates it clearly from siblings like search_corpus and read_passage, which focus on lookup rather than provenance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives explicit trigger conditions: use when the user asks what Claudette is, whose words these are, or how the guarantee is enforced. This is concrete enough for an agent to route to this tool without opening sibling definitions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_worksA

List every work in the corpus: author, title, year, why it is included, and its slug.

Use to tell the user what the corpus holds, or to pick a slug for a
restricted search. Not a search — it returns no passages.

ParametersJSON Schema

Name	Required	Description	Default
`shelf`	No	'thought' or 'fiction', or unset for all.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`status`	Yes	ok — passages found that match most of the question's terms. weak — something matched, but thinly; say so if you use it. no_coverage — the corpus does not speak to this. Say that. Do not answer from elsewhere. not_found — a specific reference did not resolve.
`constraint`	No
`provenance`	No
`limitations`	No	Part of the answer, not a disclaimer.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the output fields and explicitly states it returns no passages, which is useful. However, it does not state whether the operation is read-only, mention any permission requirements, or describe behavior such as pagination or error handling. For a simple list tool this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero fluff. The first sentence states the core function and outputs; the second provides usage guidance and an explicit exclusion. It is front-loaded and every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward list tool with an output schema and fully documented parameters, the description covers purpose, usage, and key output characteristics. It does not explicitly mention all sibling tools, but the combination of the description and schema is sufficient for an agent to call it correctly. Minor gaps around error handling or performance are not critical here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes the only parameter (shelf) with its allowed values and default, so the schema carries the semantic weight. The description does not mention the parameter at all, so it adds no value beyond the schema, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (List every work) and the exact fields returned (author, title, year, why it is included, slug), making the purpose unambiguous. It differentiates from search_corpus by explicitly stating 'Not a search', but does not explicitly distinguish itself from read_passage or corpus_provenance, so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases ('tell the user what the corpus holds' and 'pick a slug for a restricted search') and a clear exclusion ('Not a search — it returns no passages'). It implies the alternative search_corpus without naming it, and does not mention when read_passage or corpus_provenance would be preferred, so it is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_passageA

Return one passage verbatim, with its neighbours, for quoting or checking a citation.

Use after search_corpus when you need the surrounding text. Not for finding
passages — it takes a ref, not a question.

ParametersJSON Schema

Name	Required	Description	Default
`ref`	Yes	A citation ref from search_corpus, e.g. 'follett-new-state§412'.
`context`	No	How many neighbouring passages to include either side.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`status`	Yes	ok — passages found that match most of the question's terms. weak — something matched, but thinly; say so if you use it. no_coverage — the corpus does not speak to this. Say that. Do not answer from elsewhere. not_found — a specific reference did not resolve.
`constraint`	No
`provenance`	No
`limitations`	No	Part of the answer, not a disclaimer.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns the passage 'verbatim' and includes 'neighbours', which defines the output behavior, and implies a read-only operation. It also clarifies that the input is a reference, not a free-text query, which is a behavioral constraint. It does not cover error handling or edge cases, but for a simple read tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the primary purpose and scope front-loaded. The second sentence provides usage guidance and exclusion, with no redundant filler. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return values are defined elsewhere. The description covers what the tool does, when to use it, and how it differs from its sibling, and the parameters are fully documented in the schema. For a simple read operation, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented with examples and constraints. The description adds minimal additional parameter meaning: 'with its neighbours' indirectly aligns with the context parameter, but this is already in the schema. The phrase 'takes a ref, not a question' reinforces the ref parameter's type, but that is also implied by the schema. Thus the description does not add significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Return') and a precise resource ('one passage verbatim, with its neighbours') and names the intended use case ('for quoting or checking a citation'). It explicitly differentiates from the sibling tool search_corpus by clarifying that it does not find passages, so an agent can distinguish them without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear when-to-use instruction ('Use after search_corpus when you need the surrounding text') and a when-not-to-use exclusion ('Not for finding passages — it takes a ref, not a question'). This directly routes the agent to the correct tool and explains the prerequisite that the ref comes from search_corpus.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_corpusA

Find passages across the corpus that bear on a question.

Call this before answering anything of substance. Returns ranked passages,
each with a citation `ref` and the list of query terms it actually contains.
Not for reading a passage you already have a ref for — use read_passage.

ParametersJSON Schema

Name	Required	Description
`k`	No	How many passages to return.
`work`	No	Restrict to one work by slug (see list_works). Leave unset to search everything.
`query`	Yes	The idea to look for, in a few content words. Older vocabulary matches better: 'sympathy' over 'empathy', 'master and men' over 'management'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No
`status`	Yes	ok — passages found that match most of the question's terms. weak — something matched, but thinly; say so if you use it. no_coverage — the corpus does not speak to this. Say that. Do not answer from elsewhere. not_found — a specific reference did not resolve.
`constraint`	No
`provenance`	No
`limitations`	No	Part of the answer, not a disclaimer.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burdenconcern. It discloses the ranked-passage return shape, the presence of citation refs, and that it reports which query terms are actually contained. It also signals that this is a lookup/search operation, not a passage-reader, which adds useful behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, then when to use it, then key return details, then a clear exclusion with an alternative. Every sentence contributes, and there is no filler or repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a rich input schemachers, an output schema, and sibling tools, the description covers all essential invocation context: what it searches, when to call it, what it returns, and which tool to use instead. The 'work' field's reference to list_works fills any remaining routing gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 even though the main description adds no parameter-level detail. The query, k, and work parameters already have meaningful descriptions in the schema, including vocabulary guidance for query, so no compensation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Find passages across the corpus') and a clear resource ('the corpus') tied to a question, and it explicitly contrasts itself with read_passage. This is a distinctive, non-tautological purpose that an agent can immediately act on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use rule: 'Call this before answering anything of substance.' It also names the alternative for the negative case: 'Not for reading a passage you already have a ref for — use read_passage.' The schema's work parameter further references list_works, covering the sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 18, 2026
- First observedcorpus_provenance
- First observedlist_works
- First observedread_passage
- First observedsearch_corpus

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-09-18 09:35 across 4 tools

Disambiguation5/5

Each tool serves a clearly distinct function: searching, reading a specific passage, listing works, and providing provenance. No overlap or ambiguity in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (search_corpus, read_passage, list_works, corpus_provenance), making the naming predictable and intuitive.

Tool Count5/5

Four tools is well-scoped for a corpus retrieval server; each tool covers a core capability without redundancy or bloat.

Completeness5/5

The surface covers the full lifecycle of corpus interaction: discovery (list_works), retrieval (search_corpus, read_passage), and context (corpus_provenance). No obvious gaps for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Hermitsh Texts A
ai.hermitsh
Complete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
Search Art & Culture Education & Learning Tools
192
Scite AOAuth
ai.scite
Ground answers in scientific literature. Search full text, evaluate trust, access full-text articles
Search Research & Data Documentation Access
2
lens A
ai.mindola
Create your digital twin: a public page that answers from your own material, with citations.
RAG Systems Knowledge & Memory Search
31
Verbaterm Policy Intelligence A
io.github.TensorsWillFlow
Judged, citation-checked policy corpus over MCP. Keyless public reads; API key for AI tools.
Legal & Compliance Research & Data Documentation Access
71

Related MCP Servers

philosophy-mcp
Research & Data Education & Learning Tools
sea9401
A
license
A
quality
D
maintenance
Provides access to philosophy texts including scholarly papers from PhilPapers/PhilArchive and classic books from Project Gutenberg, SEP, and other open-access sources, all without requiring an API key.
Updated 4 months ago (2026-05-30 11:50 UTC)
17
8
MIT
Quotewise MCP Serverofficial
Search Knowledge & Memory
quotewise
A
license
Not graded
quality
C
maintenance
Enables semantic quote search, attribution verification, and collection management for AI assistants, with source transparency via QuoteSightings.
Updated 7 months ago (2026-02-16 04:33 UTC)
4 npm
1
MIT
library-mcp
RAG Systems Knowledge & Memory Vector Databases
Leovilhena
F
license
Not graded
quality
B
maintenance
Provides a 'library keeper' sub-agent that ingests PDF/EPUB books and answers questions grounded in them via local embedding search, with deterministic classification and knowledge gap logging.
Updated 17 days ago (2026-09-01 13:28 UTC)
-
library-mcp
RAG Systems Search Education & Learning Tools
forgemeshlabs
A
license
A
quality
A
maintenance
This MCP server enables AI agents to search and retrieve exact, cited passages from a large corpus of public-domain books, including full-text search, book metadata, chapters, quotes, and 'ask book' Q&A. Payments are handled via x402 micropayments on Base.
Updated 17 days ago (2026-09-01 18:41 UTC)
16
8
54 npm
MIT

Claudette

Why

What it is not

Use it as a connector (recommended)

Hosting it for others

Use it from the command line

How the guarantee is enforced

The corpus

Known limits, stated rather than hidden

Adding a work

Layout

Licence

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Quotewise MCP Serverofficial