Inspiration
A prior-art search is the first thing a founder needs and the last thing they can afford. A patent attorney charges four figures and takes a week to tell you whether your idea is already patented. Most people skip that step and find out the expensive way, after they have built. We wanted to collapse that first search into a minute, and to make the answer something you can trust, because every part of it is backed by a source you can open and read.
What it does
You describe an invention in one sentence. PatentPincer searches the prior art (Google Patents through SerpApi, with two or three phrasings of the invention to widen recall, plus a Scholar query for non-patent literature), pulls the claim text of the closest references through the Google Patents Details engine, compares your invention element by element against those claims, and hands back a decision-ready verdict, file it, narrow it, or walk away, with the citations attached. Every claim it makes carries a source; it never just asserts that something is or is not novel.
How we built it
SerpApi is the load-bearing data backbone. Three engines do the heavy lifting: Google Patents for search, Google Patents Details for the claim text, and Google Scholar for non-patent literature. The agent layer is a small, guarded analyst on top. It plans the query variants, books each SerpApi call against a spend budget sized to exactly one assessment, and refuses to print a verdict if the claim fetch was starved, because a degraded analysis that still prints a confident answer is the exact failure this project refuses to ship. The three tools are also served over the Model Context Protocol, so another agent can reuse the same guarded backbone. With no key present, the whole pipeline runs on a deterministic offline fixture corpus, so it is fully demoable and testable without spending a cent.
Challenges we ran into
Comparing at the claim level, not the title level: a tool that matches on titles gives false comfort, so we fetch and compare the actual claim text. Spend discipline on a metered API: the guardrail is sized to exactly the calls one assessment needs, no larger so a runaway loop is bounded, and no smaller so the claim fetch is never silently starved. Making it runnable by anyone: the offline fixture corpus mirrors the real SerpApi response shapes, so the demo, the tests, and a judge with no key all exercise the same pipeline.
Accomplishments that we're proud of
A genuinely useful first-pass patentability check that a founder could run today. Element-by-element novelty analysis grounded in real claim text, with citations, not vibes. A disciplined, spend-bounded use of SerpApi across three engines, reusable by other agents over MCP. It runs offline, keyless, and is covered by a real test suite, so the claims are checkable.
What we learned
The value is in the grounding. An answer a founder can act on has to be traceable to a source, or it is worse than no answer. On a metered API, the guardrail is a feature, not overhead: sizing spend to the real work makes the tool both safe and honest about when it cannot answer well.
What's next for PatentPincer
Wider recall with classification-aware queries using CPC codes, more Scholar depth, and a short freedom-to-operate view. A saved-search history so a founder can watch a space over time.
Built With
- ai-agents
- google-cloud
- google-patents
- google-scholar
- model-context-protocol
- patents
- prior-art
- python
- serpapi
Log in or sign up for Devpost to join the conversation.