What can you do with this server?

This server provides MCP-based aquaculture manuscript-writing agents and supporting tools for drafting, checking, and exporting journal-ready manuscripts. * Six writing agents (literature, drafting, results, abstract, copyedit, integrity) plus an orchestrator that coordinates handoffs between them. * Citation integrity checking — flags verbatim 3+ word overlaps between a draft and source texts. * Journal profile lookup — lists supported journals with abstract limits, keyword counts, citation style, and AI-disclosure requirements. * AI-use disclosure drafting — generates journal-specific AI disclosure statements only when required. * External model execution — runs any agent against an OpenAI-compatible endpoint using your own API key/model. * Automated pipeline — runs a bounded draft → check → revise → copyedit loop with a step-by-step log. * Domain calculators — FCR variants, SGR, stocking density, survival rate, unionized ammonia, and water-parameter sanity checks (Nile tilapia, Pacific whiteleg shrimp). * Real citation tools — CrossRef DOI metadata lookup, citation search, and BibTeX validation. * Statistical tools — descriptive stats, normality/homogeneity tests, t-test, ANOVA, Kruskal-Wallis, Tukey HSD, effect sizes, confidence intervals, two-way ANOVA, Pearson correlation (no model-computed p-values). * Manuscript export — builds a structured .docx with title, abstract, keywords, sections, tables, references, and AI disclosure.

How do I use Aquaculture Manuscript MCP?

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., "@Aquaculture Manuscript MCP draft the discussion section for my Nile tilapia growth trial, journal: Aquaculture" 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.

Aquaculture Manuscript MCP

by oceanfarm1992-design

Overview Schema Source Related Servers Discussions Admin

Python

Local

Aquaculture Manuscript MCP

An MCP server that exposes aquaculture manuscript-writing agents — derived from this project's RACI matrix — to Claude Desktop, Claude Code, or any other MCP-compatible client. Once installed and connected, the agents show up inside your normal chat; no copy-pasting prompts. They also hand work to each other on real defects (see "Agents talking to each other" below) rather than drafting everything in one uncoordinated pass.

What it is

Six writing agents, one per AI-automatable role in the RACI matrix, plus an orchestrator that hands work between them:

Agent	RACI role	Does
`literature-agent`	Information & Lit Experts	Finds/vets real citations, never fabricates them
`drafting-agent`	Writing & Editorial	Drafts Introduction, Materials & Methods, Discussion
`results-agent`	Writing & Editorial (from supplied data)	Turns your real data/tables into Results prose
`abstract-agent`	Writing & Editorial	Title, Abstract, Keywords (journal-specific limits)
`copyedit-agent`	Writing & Editorial	Sentence-level polishing, never changes claims/data
`integrity-agent`	AI & Plagiarism	Real citation-overlap check + journal-aware AI-use disclosure
`orchestrator-agent`	—	Coordinates the six above using real handoff rules

Roles that stay human-only regardless of model (PI accountability, IACUC/legal, physical data collection, grant sign-off, peer review, running an actual similarity-scan tool) are listed via the aquaculture://human-only-roles resource — the server does not attempt them.

Journal rules are not hard-coded. Abstract word limits, keyword counts, citation style, and whether an AI-use declaration is required all differ by journal (confirmed: Elsevier's Aquaculture requires a 250-word abstract, 5-7 keywords, and a mandatory AI-disclosure statement; Wiley's Aquaculture Research is a 200-word abstract, 4-6 keywords, APA citations, and its AI-disclosure policy wasn't visible in the guide pages checked). The abstract-agent, drafting-agent, and integrity-agent prompts take an optional journal argument (a key from list_supported_journals); without one, they're instructed to ask you which journal applies rather than default to a number from a different one.

This server does not help evade AI-detection or plagiarism-scan tools. Every agent is built to disclose AI assistance (see integrity-agent / draft_ai_disclosure) and to never fabricate data or citations. See src/aquaculture_manuscript_mcp/agents.py for the exact rules baked into each one.

Related MCP server: pubmed-search-mcp

Install

Requires Python 3.10+.

git clone https://github.com/oceanfarm1992-design/aquaculture-manuscript-mcp.git
cd aquaculture-manuscript-mcp
pip install -e .

This installs the aquaculture-manuscript-mcp command, which runs the server over stdio (the standard MCP transport for desktop clients).

Find the right `command` path for your MCP client — read this before wiring it up

This is the step that actually trips people up, so it gets its own section. Your MCP client (Claude Desktop, Claude Code, etc.) launches the server as its own process — it does NOT inherit your terminal's activated virtualenv.

If you installed with no virtualenv (system/user Python) and your Python Scripts/bin directory is on PATH, the bare command aquaculture-manuscript-mcp will work as-is in the config below.
If you installed inside a virtualenv (recommended, and what these docs' own testing used), the bare command will silently fail to launch — the client has no way to find it. Use the absolute path to that venv's copy of the entry point instead:
- Windows: <path-to-repo>\.venv\Scripts\aquaculture-manuscript-mcp.exe
- macOS/Linux: <path-to-repo>/.venv/bin/aquaculture-manuscript-mcp
Find it quickly with where aquaculture-manuscript-mcp (Windows, venv activated) or which aquaculture-manuscript-mcp (macOS/Linux).

Connect it to Claude Desktop

Edit Claude Desktop's config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add an entry under mcpServers, using whichever command applies from the section above (Windows paths need double backslashes in JSON):

{
  "mcpServers": {
    "aquaculture-manuscript-writing": {
      "command": "aquaculture-manuscript-mcp"
    }
  }
}

or, for a virtualenv install on Windows:

{
  "mcpServers": {
    "aquaculture-manuscript-writing": {
      "command": "C:\\path\\to\\aquaculture-manuscript-mcp\\.venv\\Scripts\\aquaculture-manuscript-mcp.exe"
    }
  }
}

Restart Claude Desktop. The six agents now appear as prompts you can attach to a conversation (paperclip / prompts menu), and the two tools (citation-integrity check, AI-disclosure drafting) are available for Claude to call directly.

When run this way, the prompts use Claude itself to draft — no API key needed.

Connect it to Claude Code or any other MCP client

Any MCP-compatible client works the same way — point it at the same command (same caveat about venv vs. system Python applies). For Claude Code specifically, add the same mcpServers block to a .mcp.json file in your project root instead of editing a global config file. Consult other clients' docs for where they keep MCP server config.

Verify it's working before wiring it into a client

The MCP Inspector can connect directly to the installed command and let you call tools by hand — useful for confirming the install before trusting a client's UI. Its exact CLI flags differ between v1 and v2 and are moving targets, so check its own README for the current invocation; point it at the same command path from the section above.

Using a different / specific model (bring your own token)

If you want a particular agent to run against a specific model — not just whatever model your MCP client happens to use — call the run_agent_with_external_model tool. It talks to any OpenAI-compatible endpoint (OpenAI itself, a local Ollama/LM Studio server, or any other provider that mirrors the OpenAI chat-completions API).

Set these as environment variables in your MCP client's server config (env block) — never pass the API key as a tool argument or in chat:

{
  "mcpServers": {
    "aquaculture-manuscript-writing": {
      "command": "aquaculture-manuscript-mcp",
      "env": {
        "AQUA_API_KEY": "sk-...",
        "AQUA_BASE_URL": "https://api.openai.com/v1",
        "AQUA_MODEL": "gpt-4o-mini"
      }
    }
  }
}

AQUA_BASE_URL defaults to https://api.openai.com/v1 if omitted; point it at any other OpenAI-compatible base URL to use a different provider. See .env.example for a local-development template (useful if you run/test the server outside an MCP client).

Agents talking to each other

The agents hand work back and forth when a specific, nameable defect is found — not to make accurate text merely read as less AI-generated. Full rules are in aquaculture://handoff-rules (also in agents.HANDOFF_RULES); the short version:

drafting-agent output goes to copyedit-agent, then integrity-agent.
integrity-agent (or check_citation_integrity) finds a verbatim overlap with a source -> the flagged phrase goes back to drafting-agent with an explicit instruction to paraphrase in original sentence structure -> re-check.
integrity-agent finds an unsupported background claim -> handed to literature-agent to find a real citation. An unsupported results claim is never handed off to be invented — the loop stops and asks you instead.
abstract-agent's numbers get cross-checked against results-agent's actual output before anything is called final.

Two ways to use this:

orchestrator-agent prompt — attach it in Claude Desktop (or any MCP client) instead of an individual agent prompt. It instructs the connected model to call the other prompts/tools in the right order and actually perform the handoffs, using no API key (it runs on your client's model).
run_pipeline tool — a concrete, bounded implementation of the citation-overlap handoff (rules 1–2 above) that runs headlessly against an external model via AQUA_API_KEY: draft -> check -> revise (only if a real overlap was found) -> re-check -> copyedit, capped at max_revisions and returning a full step-by-step log so nothing happens silently.

Tools reference

check_citation_integrity(draft_text, source_texts) — flags any run of 3+ consecutive words shared between your draft and a source, no LLM call involved. A real paraphrase check.
list_supported_journals() — returns the known journal profiles (abstract limit, keyword count, citation style, AI-disclosure requirement), each with only facts confirmed by actually reading that journal's author guide.
draft_ai_disclosure(tool_name, reason, journal="") — returns the exact "Declaration of generative AI use" paragraph text, but only once journal identifies a profile confirmed to require one; otherwise it tells you to ask rather than guessing.
run_agent_with_external_model(agent_name, task_input, journal="", model=None, base_url=None) — runs any of the six agents against an external OpenAI-compatible model using AQUA_API_KEY.
run_pipeline(task_input, source_texts=None, journal="", max_revisions=2, model=None, base_url=None) — the bounded draft/check/revise/copyedit loop described above; returns {final_text, revisions_used, clean, log}.

Domain calculators (pure math, no LLM call, fully unit-tested)

calculate_fcr, calculate_biomass_corrected_fcr, calculate_economic_fcr — feed conversion ratio and its variants (formula documented per function; terminology for "eFCR"/"bFCR" varies by source, so state your exact method in Methods rather than relying on the label).
calculate_sgr — specific growth rate, SGR = (ln(Wf) - ln(Wi)) / days x 100.
calculate_stocking_density — biomass per volume (kg/m3) and/or area (kg/m2).
calculate_survival_rate — survival % and cumulative mortality %.
calculate_unionized_ammonia — NH3-N fraction/concentration from TAN, pH, and temperature (Emerson et al. 1975 equilibrium equation — general aquatic chemistry, not species-specific).
check_water_parameter(species, parameter, measured_value) / list_water_quality_reference_species() — checks a value against a cited reference range. Only two species are covered (Nile tilapia, Pacific whiteleg shrimp) because those are what a source-backed range could actually be found for — an unlisted species means "not yet sourced," not "no threshold exists." Every result carries its source and a caveat that it's a sanity check, not a citable threshold by itself.

Real citation tools

resolve_doi_metadata(doi) / search_citations(query, rows=5) — real lookups against the CrossRef registry (api.crossref.org), so the literature-agent's "never fabricate a citation" rule has an actual external source to check against instead of relying on model memory.
validate_bibtex(bibtex_text) — parse errors, missing required fields per entry type, duplicate keys, entries with no DOI/URL.

Real statistics (scipy/statsmodels — the model never computes a p-value itself)

descriptive_stats, check_normality (Shapiro-Wilk), check_variance_homogeneity (Levene's).
analyze_ttest (Welch's by default), analyze_anova, analyze_kruskal_wallis.
analyze_posthoc_tukey — pairwise Tukey HSD with adjusted p-values and CIs for 3+ groups. Does not auto-generate a/b/c significance letters. Naive greedy letter-assignment gets this wrong in cases where a group must share a letter with two other groups that are themselves significantly different from each other — this is exactly why R's multcompView package exists as dedicated, carefully-verified machinery rather than a one-line loop. Getting it wrong would silently mislabel a published table, so this tool returns the full, unambiguous pairwise matrix instead and leaves letter-assignment to a human (or a future, properly-verified implementation) — see the module docstring in tools/statistics.py.
calculate_effect_size_cohens_d, calculate_eta_squared, calculate_confidence_interval.
analyze_two_way_anova — two-way factorial ANOVA with interaction term (Type II SS), for crossed two-treatment designs (e.g. diet x feeding frequency) — the standard layout for most nutrition trials, not an edge case. Validated against an independently hand-written statsmodels script on a real 18-tank tilapia trial (exact match on F/eta-squared for every term). Factor names are never interpolated into the underlying formula string.
calculate_pearson_correlation.

Manuscript export

export_manuscript_docx(output_path, title, abstract, keywords, sections, authors=None, tables=None, references=None, ai_disclosure=None) — assembles real structured content into an actual .docx file (Times New Roman, title/abstract/keywords block, heading-per-section, native Word tables, hanging-indent references, AI-disclosure section). Renders exactly what it's given — a missing section stays missing rather than being filled with something plausible-sounding.

Deployment

Default transport is stdio (what Claude Desktop/Code and most local MCP clients expect). For a remote/cloud deployment, set AQUA_TRANSPORT=sse or AQUA_TRANSPORT=streamable-http in the environment before running the server. A Dockerfile is included:

docker build -t aquaculture-manuscript-mcp .
docker run -e AQUA_TRANSPORT=stdio -i aquaculture-manuscript-mcp

Development

python -m venv .venv
source .venv/bin/activate   # or .venv\Scripts\activate on Windows
pip install -e ".[dev]"
pytest -q                    # or: pytest -q -m "not network" to skip CrossRef calls
aquaculture-manuscript-mcp   # runs the stdio server directly, for manual testing

mcp dev src/aquaculture_manuscript_mcp/server.py also works (launches the MCP Inspector against this file directly) as long as the package itself is installed in the environment mcp dev runs in — it imports server.py in a way that requires aquaculture_manuscript_mcp to already be a real, importable package, not just a loose file.

License

MIT — see LICENSE.

Available Tools

4 tools

check_citation_integrityA

Flag verbatim word-runs of 3+ words shared between a draft passage and one or more source texts — a real paraphrase check, not AI-detection evasion.

ParametersJSON Schema

Name	Required	Description	Default
`draft_text`	Yes
`source_texts`	Yes

TDQS

A4.2/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 behavioral disclosure burden. It reveals the core algorithm, the exact 3-word threshold, and the boundary that this is not an AI-detection bypass tool. It does not describe the output format, but the behavior itself is stated specifically and honestly.

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 a single, front-loaded sentence with no filler. The verb, object, and rule appear first, and the contrast clause 'not AI-detection evasion' earns its place by preventing misuse.

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 low-complexity tool with two plain parameters and no output schema, the description covers the input semantics, the matching rule, and the intended use. It omits an explicit return format, but 'Flag...' implies the result is the flagged overlap, so the gap is minor.

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 0%, so the description must compensate. It lightly maps draft_text to 'draft passage' and source_texts to 'one or more source texts,' but it does not detail parameter expectations such as length limits, plain-text assumptions, or normalization rules. The parameter names are self-explanatory, so this is adequate but not rich.

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 starts with a specific verb ('Flag') and identifies the exact resource and rule: verbatim word-runs of 3+ words shared between a draft passage and source texts. It also distinguishes itself from AI-detection evasion, making the tool's purpose and non-purpose immediately clear.

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 clearly implies the tool is for real paraphrase assessment and explicitly says it is 'not AI-detection evasion,' which works as a when-not-to-use signal. It does not name sibling alternatives or provide formal usage conditions, so it stops short of a 5.

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

draft_ai_disclosureA

Produce the 'Declaration of generative AI use' statement text for the given tool name and reason it was used — IF the target journal is known to require one. Pass journal (a key from list_supported_journals) so this can check; without it, this returns a prompt to ask the user instead of guessing whether a disclosure is required or what it should say.

ParametersJSON Schema

Name	Required	Description	Default
`reason`	Yes
`journal`	No
`tool_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/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 discloses the conditional nature of the tool, the dependency on a valid journal key, and the no-guessing fallback when journal is absent. The only ambiguity is what happens when a provided journal is valid but does not require a disclosure, which is likely covered by the output schema but not explicitly stated.

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 deliver the core purpose, key condition, and fallback behavior with no filler. The main outcome is front-loaded, and the dependency on `journal` is placed immediately after the purpose, giving an agent the essential information in order.

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 text-generation tool with an output schema and no destructive side effects, the description covers the required inputs, the prerequisite journal key, and the omission fallback. The main unstated detail is the exact branch when a valid journal does not require a disclosure, but that is a modest gap given the output schema exists.

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?

Schema description coverage is 0%, so the description must compensate. It does by connecting `journal` to `list_supported_journals` and explaining its role in the requirement check, while also framing `tool_name` and `reason` as the subject and rationale of the generated statement. It stops short of giving format examples, but the property names plus this context are sufficient for correct invocation.

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 identifies a concrete deliverable ('Declaration of generative AI use' statement text) and specifies the two inputs that drive it: tool name and reason. It clearly conditions the task on the target journal requiring a disclosure, but it does not explicitly distinguish the tool from sibling tools like check_citation_integrity.

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?

It explicitly tells callers to pass `journal` from `list_supported_journals` so the tool can check whether a disclosure is required, and it explains the fallback behavior when journal is omitted: return a prompt asking the user. This is clear context for when to call the tool, but it does not state exclusions or name an alternative tool for the same task.

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

list_supported_journalsA

List known journal formatting profiles (abstract word limit, keyword count, citation style, AI-disclosure requirement). Use this to ask the user which journal applies before drafting an abstract or AI-disclosure statement — never assume one journal's limits apply to another.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly describes a read-only listing operation and specifies what information is returned. Adding an explicit statement that it has no side effects or that the list is static would strengthen it further.

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 focused sentences: the first states the action and output, the second gives workflow guidance. Every sentence earns its place with no repetition or filler.

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?

For a zero-parameter listing tool with no output schema, this description is complete. It tells the agent what the tool returns, when to use it, and why it matters, so the agent can invoke it correctly without additional information.

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?

The tool has zero parameters and the schema is trivially complete, so there are no parameters needing documentation. The baseline of 4 applies because parameter semantics are not a concern here.

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 uses a specific verb ('List') and a clear resource ('known journal formatting profiles'), and it enumerates the actual contents of those profiles. It is immediately distinguishable from sibling tools that check citations, draft AI disclosures, or run external agents.

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 explicitly states when to use the tool: ask the user which journal applies before drafting an abstract or AI-disclosure statement. It also warns against assuming one journal's limits apply to another, which gives practical usage context, though it does not explicitly name an alternative tool.

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

run_agent_with_external_modelA

Run one of the six manuscript-writing agents against an external OpenAI-compatible model, instead of the model your MCP client already uses.

The API key is never passed as an argument here — set it once as the AQUA_API_KEY environment variable in your MCP client's server config.

agent_name: one of "literature", "drafting", "results", "abstract", "copyedit", "integrity". journal: a key from list_supported_journals, for agents whose rules are journal-specific (abstract, drafting, integrity). Leave blank and the agent will ask the user which journal applies instead of guessing. model: overrides the AQUA_MODEL environment variable for this call. base_url: overrides the AQUA_BASE_URL environment variable for this call (defaults to https://api.openai.com/v1; point this at any OpenAI-compatible endpoint, e.g. a local Ollama/LM Studio server).

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`journal`	No
`base_url`	No
`agent_name`	Yes
`task_input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses important behavioral traits: the API key is never passed as an argument, it must be set as an environment variable, and the model/base_url parameters override environment variables. It also explains the journal parameter behavior (leave blank and the agent will ask the user). This goes beyond what annotations provide (none) and gives the agent actionable operational knowledge.

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

Conciseness4/5

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

The description is well-structured with a clear opening sentence followed by parameter explanations. It's slightly longer than necessary but every sentence adds value. The parameter list is front-loaded after the main purpose statement, making it easy to scan.

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?

Given the tool's complexity (5 params, 0% schema coverage, no annotations), the description covers the key operational details: agent selection, journal behavior, environment variable overrides, and external endpoint configuration. The output schema exists, so return values don't need explanation. Minor gap: task_input is not explicitly described, but its purpose is clear from context.

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?

Schema description coverage is 0%, so the description carries the full burden. It explains agent_name (with the six valid values), journal (with reference to list_supported_journals and behavior when blank), model (overrides AQUA_MODEL), and base_url (overrides AQUA_BASE_URL with default). The only parameter not explicitly described is task_input, but its meaning is inferable from the tool's purpose. This is strong compensation for the schema gap.

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 clearly states the tool's purpose: run one of six manuscript-writing agents against an external OpenAI-compatible model. It names the specific agents and distinguishes this from the default model usage. The verb 'run' plus the resource 'manuscript-writing agents' is specific and unambiguous.

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 explains when to use this tool (when an external model is needed instead of the MCP client's default) and provides setup context (AQUA_API_KEY environment variable). It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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 observedcheck_citation_integrity
- First observeddraft_ai_disclosure
- First observedlist_supported_journals
- First observedrun_agent_with_external_model

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.3/5.0

Scored 2026-09-18 10:45 across 4 tools

Disambiguation5/5

Each tool targets a distinct operation: checking citation integrity, listing journal profiles, drafting AI disclosures, and running writing agents. No two tools overlap in purpose; descriptions even cross-reference each other to prevent misselection (e.g., draft_ai_disclosure requires a journal key from list_supported_journals).

Naming Consistency4/5

All tool names use snake_case with a leading verb (check, list, draft, run) followed by a noun phrase. The pattern is consistent, though 'run_agent_with_external_model' is longer and embeds a qualifier, making it slightly less parallel than the others. Overall, naming is predictable.

Tool Count5/5

With 4 tools, the server is well-scoped for its niche purpose of supporting aquaculture manuscript writing. Each tool has a clear role, and none feels redundant or missing. The count is appropriate for a focused MCP server.

Completeness4/5

The tools cover the core workflow: checking citation integrity, retrieving journal requirements, generating AI disclosures, and running various writing agents. Minor gaps exist (e.g., no explicit tool to list agents, but run_agent_with_external_model includes the list in its description; no direct formatting tool, but agents likely handle it). Overall, the surface is reasonably complete for the stated domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
slimaOAuth
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21
Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
Aibooma - AI Agent Registry
com.aibooma
AI agent registry — search, discover, register, and connect agents via MCP.
Agent Orchestration Search Developer Tools
2

Related MCP Servers

Storywright MCP
AI & Machine Learning Autonomous Agents Content Management Systems
BurgersJackson
F
license
C
quality
D
maintenance
A multi-agent book-writing MCP server that manages a guarded chapter pipeline (writer → editor → third-pass agents → approve) with project planning, continuity tracking, and export/diff helpers.
Updated 5 months ago (2026-04-28 04:32 UTC)
35
-
pubmed-search-mcp
Research & Data Search AI & Machine Learning
u9401066
A
license
A
quality
B
maintenance
An intelligent research assistant MCP server for AI agents, providing task-oriented literature search and analysis across multiple academic databases.
Updated 2 days ago (2026-09-18 11:24 UTC)
41
490 PyPI
28
Apache 2.0
scholar-memory
RAG Systems Research & Data
byBasiliosP
A
license
Not graded
quality
D
maintenance
Enables scientific literature research through multi-agent search, analysis, and semantic memory, exposing 9 MCP tools for querying, storing, and retrieving research findings.
Updated 3 months ago (2026-06-06 14:37 UTC)
1
MIT
forge-mcp
Coding Agents Code Analysis Autonomous Agents
erewhon
A
license
Not graded
quality
B
maintenance
Provides MCP tools for AI-powered code review, research, and book writing via a fleet of coding agents.
Updated 2 days ago (2026-09-18 10:40 UTC)
Apache 2.0

Aquaculture Manuscript MCP

What it is

Install

Find the right command path for your MCP client — read this before wiring it up

Connect it to Claude Desktop

Connect it to Claude Code or any other MCP client

Verify it's working before wiring it into a client

Using a different / specific model (bring your own token)

Agents talking to each other

Tools reference

Domain calculators (pure math, no LLM call, fully unit-tested)

Real citation tools

Real statistics (scipy/statsmodels — the model never computes a p-value itself)

Manuscript export

Deployment

Development

License

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Find the right `command` path for your MCP client — read this before wiring it up