Patents

Quality – / 100not scored

Not scored: fewer than three checks apply, usually because no remote answered a credential-free probe or the server is a local package.

Tool list unknown · tools last changed 2026-10-17 · checked 2026-10-20 13:49 UTC

Tool changes

• 2026-10-17search_inventorsremoved

  Search USPTO patent applications by inventor last name. Returns matching applications with title, inventor list, and filing date — sorted newest-filed-first, so this is the APPLICATION corpus (same as search_patents with no `granted_after`), and the newest rows will be unexamined filings with no grant date by construction (USPTO publishes ~18 months after filing). That is expected, not stale data. For a specific inventor's ISSUED patents, use search_patents with `inventor` + `granted_after` instead.

• 2026-10-17get_patentremoved

  Fetch a single USPTO patent application/grant by application number (e.g., "16/123,456" or "16123456"). Returns full metadata: title, inventors, classifications, status, prosecution events. A returned record with no grant event and no grant date is not stale — it means that specific application has not yet been examined/granted; check `status` and `grant_event` rather than assuming the record is out of date.

• 2026-10-17search_patentsremoved

  Search USPTO patent applications and grants — **without a `granted_after`/`granted_before` bound this returns the APPLICATION corpus sorted newest-FILED-first, not issued patents.** USPTO publishes an application ~18 months after filing and typically takes 2+ years to grant it, so the newest rows in an unfiltered search are always recent, unexamined filings with `grant_date: null` — that is expected, not stale data. **Pick the date field on the QUESTION'S VERB, not on the word "recent":** a question asking who has FILED / applied for / sought patents in a window wants `filed_after`/`filed_before` — the default application corpus already includes pending AND granted patents, so no `granted_after` is needed or wanted, and adding one will silently drop recently-filed-but-not-yet-examined applications (grant lags filing by 2+ years, so "filed in the last 3 years" AND "granted in the last 3 years" are mostly DISJOINT sets). Only use `granted_after`/`granted_before` when the question explicitly says GRANTED / ISSUED / APPROVED / "has a patent" (not just "recent patents"). Use `query` for free-text keywords ("lithium battery", "crispr", "machine learning"); all terms are required (AND), and you can quote a phrase to keep it together. A curated, short list of known synonym/abbreviation pairs for concepts that patents describe inconsistently (e.g. cfRNA / cell-free RNA / circulating RNA; MRD / minimal residual disease / residual cancer) is recognized in `query` — quoted or bare — and expanded to an OR group before the search runs, so "cfRNA" and "cell-free RNA" are treated as the same concept rather than requiring the caller to guess a specific patent's exact wording (marked `synonyms_expanded: true` in the response; this is a fixed, documented list, not general synonym invention). A question that names several DISTINCT ways of describing the same idea (e.g. a condition plus a detection method, each expressed as its own quoted phrase) should still be passed as one query — if the literal AND-of-everything match returns zero, the tool automatically retries once with those same quoted phrases OR'd together instead and marks the response `broadened: true`; it only ever relaxes multi-phrase AND to OR on a genuine zero, so a search that is narrow for a real reason (e.g. one specific applicant with no matching filings, or an ordinary bare-keyword AND) still correctly returns zero. Optional structured filters: `applicant` (exact corporate name as filed, e.g. "APPLE INC."), `inventor` (person name), `title` (words in the invention title), `number` (a specific application number), `filed_after` / `filed_before`, `granted_after` / `granted_before`. Common synonyms are understood — `assignee`, `company` and `owner` all reach `applicant`, and `keywords`, `q` or `text` all reach `query`. Results include title, application number, filing date, first applicant, all applicants, inventors, status, classification. `total` is the full match count but USPTO returns at most 25 records per search — narrow with applicant or a date range rather than raising `limit`. Powered by the USPTO Open Data Portal (data.uspto.gov).

• 2026-10-17forgetremoved

  Delete a previously stored memory by key. Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier. Pair with remember and recall.

• 2026-10-17rememberremoved

  Save data the agent will need to reuse later — across this conversation or across sessions. Use when you discover something worth carrying forward (a resolved ticker, a target address, a user preference, a research subject) so you don't have to look it up again. Stored as a key-value pair scoped by your identifier. Authenticated users get persistent memory; anonymous sessions retain memory for 24 hours. Pair with recall to retrieve later, forget to delete.

• 2026-10-17pipeworx_feedbackremoved

  Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server in your client (another vendor's Gmail, Splunk, Slack, etc. connector), we cannot fix it and reporting it here only delays you; file it with that server instead. Not sure? Pipeworx tool names are the ones this connection lists. Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. Filing without an account returns a `claim_token`; pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed and what changed. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.

• 2026-10-17generate_llms_txtremoved

  Generate a production-ready llms.txt file for any URL so AI crawlers (ChatGPT, Claude, Perplexity) can index the site cleanly. Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format. Output is a single text blob ready to drop at site-root/llms.txt. Useful for: getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor.

• 2026-10-17suggest_questionsremoved

  What can I ask Pipeworx? / what is Pipeworx good for? / what can you do? / give me ideas / show me examples / getting started / what data do you have? — the onboarding entry point for an agent that just connected and wants to know what is worth asking. Returns category-bucketed example questions (company financials, drugs & clinical trials, economics, real estate, prediction markets, weather, government & patents, science & academia, news) — each with the exact tool + argument shape that answers it, drawn from the live catalog of thousands of tools. Call with no arguments for the full spread, or pass `topic` (e.g. "finance", "pharma", "betting") to focus. Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools (ask_pipeworx, entity_profile, compare_entities, etc.).

• 2026-10-17pipeworx_trendingremoved

  What other AI agents are calling on Pipeworx right now. Returns the top tools, top packs, and total call volume over a recent window (24h, 7d, or 30d). Useful for: (1) discovering what data sources are hot for current events, (2) confirming a popular tool is the canonical choice before asking your own question, (3) seeing whether your use case aligns with what most agents need. Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.

• 2026-10-17research_rowremoved

  Claygent-style per-row research: answer ONE question about ONE company and return a JSON object matching your output_schema, with every field wrapped in its own evidence — {value, evidence_url, quote, status}. status is NEVER self-reported by the model: "found" means this code independently verified the model's quote is a VERBATIM substring of text actually fetched; "inferred" means a value was given but the quote could not be verified; "not_established" means no source answered the field, and its value is always null — never guessed, never a blended score. Sources: "web" fetches the company's own site (entity.domain required — homepage, /about, /leadership) via fetch_url; "catalog" checks entity_profile (SEC EDGAR; resolved:false for a private company is expected, not a failure); "both" (default) tries both. max_cost (USD, default 0.02, max 0.50) scales how many pages are fetched and refuses up front if it is too small to pay for even one extraction call (floor $0.002) — never silently overspends. A row where every source comes back empty costs nothing: every field is mechanically not_established with NO model call made. For a boolean/derived field (e.g. "does this company sell to healthcare"), the quote only has to SUPPORT the value — a descriptive sentence about customers/products counts, the source need not state the answer verbatim. leadership_page_status ("fetched"|"not_found"|"not_attempted", plus leadership_note) says plainly whether a leadership/team page was actually read, so a named-person field (head_of_sales) coming back not_established is distinguishable from "this company just doesn't publish one" vs. "we never checked". model_output_empty:true means the model returned nothing usable (a transport/budget problem) — every field is not_established for THAT reason, never read as 20 individual "no" judgments. Use with a fixed question + schema across many rows for "Claygent over N companies with a hard cost cap" (composes with batch callers). For picking from a fixed label list instead of extracting open fields, use classify_row (cheaper, one model call).

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.