KevLehman/article-validator

★ 0Forks 0PythonGitHub ↗Compare

README

Technical Article Validator

A multi-agent pipeline that reviews a Markdown technical article before you publish it, then optionally saves the result back to dev.to as a draft. Built on Google's Agent Development Kit (ADK). Concierge-track entry for a Kaggle agents hackathon.

The problem

Publishing a technical article means checking several different things at once: are the claims true, does the code actually run, is the writing clear, and will anyone find it. Those are different kinds of review, and doing them by hand is slow and easy to half-do. This tool runs them as separate agents in parallel and hands back one report.

What it does

Paste a Markdown draft. The pipeline:

  • pulls the verifiable technical claims out of the article,
  • fact-checks those claims against current sources with Google Search,
  • statically reviews the fenced code blocks for syntax and logic errors,
  • flags clarity, structure, and assumed-knowledge problems,
  • grounds dev.to SEO suggestions (title, tags, meta description, cover idea) in tags and rising articles pulled live from dev.to,
  • and writes a single pre-publish report: an overall status, must-fix issues, recommended improvements, what's working, and the top SEO wins.

You can then save the draft to dev.to (unpublished) with the report tucked into an HTML comment so it is visible while editing but hidden when rendered.

Architecture

A SequentialAgent with three stages:

claim_extractor
      |
      v
ParallelAgent ── fact_checker   (google_search)
              ── code_reviewer  (static, no tools)
              ── tone_reviewer  (no tools)
              ── seo_advisor    (dev.to MCP toolset)
      |
      v
report_writer

Each LlmAgent writes to its own output_key in session state; later stages read those via {key} substitution in their instructions. The four parallel reviewers write to four distinct keys so they never race on the same one.

ADK concepts it demonstrates

  • SequentialAgent and ParallelAgent composition with shared session state.
  • State hand-off between agents through output_key and {key} instruction templating.
  • A built-in tool (google_search) and an MCP toolset running as siblings inside a ParallelAgent — built-in tools cannot be mixed with other tools in one agent, and code_execution cannot run in a sub-agent, which is why code_reviewer is static.
  • An MCP toolset over Streamable HTTP (the dev.to server at /mcp).
  • An agent that acts, not just advises: the draft export calls the MCP create_article tool with published: false.

Setup

Needs Python 3.12 and uv.

uv sync
cp .env.example .env   # then fill in GOOGLE_API_KEY

GOOGLE_API_KEY is a Gemini API key. DEVTO_API_KEY is only needed if you want the draft-export feature to write to a real account — it is consumed by the dev.to MCP server, not by this app.

Run

With docker-compose (brings up the dev.to MCP server and the app together):

docker compose up --build

The app is at http://localhost:7860. Inside the compose network it reaches the MCP server at http://dev-to-mcp:3000/mcp.

Outside compose, start the MCP server yourself and run the app against localhost:

docker run --rm -p 3000:3000 docker.io/nickytonline/dev-to-mcp:latest
uv run python app.py

The app defaults DEVTO_MCP_URL to http://localhost:3000/mcp.

On secrets

GOOGLE_API_KEY and DEVTO_API_KEY live in the environment and never touch the code or the repository. .env is gitignored; only .env.example with empty placeholders is committed. Input is guarded only for emptiness and length — the real security boundary here is keeping the keys in env.

Contributors

KevLehman

Issues