Tool search 101,866 tools · 5,225 live servers

Return verbatim text from the Federal Council Botschaft (or Erläuterungsbericht) explaining the legislative purpose of a specific article. Joins the verbatim Botschaft corpus (post-2003 BBl publications, Akoma Ntoso XML where available, PDF fallback otherwise) with the article-Botschaft link table. Returns one entry per source — original Botschaft + any amendment Botschaften. All paragraphs are verbatim text the LLM can quote with `bbl_citation, S. {page}` references. USE THIS when the user asks 'what was the purpose of Art. X' or 'what did Parliament intend' or 'why does Art. X exist'. Coverage is rolling — empty `sources` means the verbatim corpus hasn't ingested that article's Botschaft yet; fall back to get_doctrine for the digest layer.

Retrieve the FULL TEXT and article list of a specific Swiss law, federal or cantonal, by LexFind ID or SR/systematic number. For federal laws in the Fedlex mirror this is instant (local SQLite). For cantonal laws, the law is downloaded from LexFind as PDF, parsed with PyMuPDF, and segmented into articles (cached 30 days). Returns: title, entity, articles (article_num, heading, text), full_text, article_count. Use search_legislation first to find the right lexfind_id or systematic_number; then pass it here. For the core federal codes, get_law is still the fastest path.

Use this tool when the question involves federal ADMINISTRATIVE PRACTICE (Verwaltungspraxis): Wegleitungen, Kreisschreiben, MWST-Infos, Weisungen, Rundschreiben, Vollzugshilfen — interpretive agency guidance, not court decisions. 1,892 documents: SECO commentary on the Arbeitsgesetz and ArGV 1-5, article by article (1,102, DE/FR/IT — the reference for employment-law questions); ESTV tax and VAT (438, DE/FR/IT); BAFU environment (297, DE); SEM migration/asylum/citizenship (55, DE). Returns ranked excerpts with authority, document number, date and a PDF link. NOT covered: BSV/AHV-IV, FINMA, BAG and all cantonal administrations — say so rather than implying a gap is an absence of guidance. For federal administrative decisions before 2017 use search_decisions(court='ch_vb') (VPB/JAAC).

Retrieve a single federal administrative-practice document by its doc_id (e.g. 'estv_ks_ks_nr_28', 'sem_weisungen_weisungen-aug-d'). Returns full body text, title, date, issuing authority, and PDF URL. Use search_practice first to discover the doc_id.

Full-text search inside type-approval document bodies (PDF text). Covers ОТТС / ОТШ / ЗОТТС / ЗОТШ. Other document kinds (СБКТС / ЗОЕТС / СУТ / cert / decl) are not covered by full-text search. **Premium feature** — requires a plan that includes full-text search (see https://hpt.su/pricing/) with a subscription covering at least one type-approval kind.

List the files attached to a document. Returns `[{file_uid, file_name, kind, pages_count, published_at}]` — each entry's `file_uid` can be passed to `download_document_file`. A document often has several PDFs (e.g. cleaned + original); use this tool to enumerate them and pick the right one before download.

Issue a personal URL to download the document PDF from hpt.su. Returns `{download_url, file_name, kind, document_id}`. The link is personal: opening it works only when signed in to hpt.su under the same account that owns the API key. The download quota is charged at actual download time, not when the link is issued. Requires an active subscription covering the document's kind or a one-time purchase of this document. On the free tier returns 403 with an upgrade prompt to https://hpt.su/pricing/.

Tailor a resume to a SPECIFIC job — TWO steps. STEP 1 (default; action omitted or 'prepare'): the server returns the job's full JD, its must-have skills/requirements, and the candidate's current resume, plus tailoring instructions. YOU (the model) then WRITE the tailored resume as JSON Resume, following the instructions — weave JD keywords into existing bullets only where the candidate genuinely has the experience, never fabricate experience/titles/dates/employers, keep all dates and company names, and flag any keyword you couldn't honestly add. STEP 2: call this tool again with action:'save', tailored_resume:<your JSON Resume>, and job_id — the server renders a PDF and saves it to the candidate's Workopia dashboard (requires sign-in). Use whenever the user references a specific job to tailor for: 'tailor for #1', 'for Morgan Stanley', 'tailor my resume for this role: <JD>'. Resolving job_id (same rules as job_detail_tool): from the most recent prior search/refine result — (a) numeric/ordinal → the Nth job; (b) company name → Company-field match; (c) role/title phrase → Job-Title match — then pass that job's **Job Id** value VERBATIM. Do NOT use placeholders like 'JOB_1' or '#1'. For STEP 1 supply ONE of job_id (preferred — server fetches the JD from Mongo) OR job_description, plus the candidate's resume via resume_text / resume_content / resume_data. For general 'improve my resume' (no specific job), do NOT call this tool — call resume_tool action=improve instead. Note: the tailored resume is written by your AI client's own model — the assistant you are already using — so it works out of the box with nothing to configure; Workopia runs no LLM of its own and never charges for the AI.

Write a cover letter for a SPECIFIC job — TWO steps. STEP 1 (default; action omitted or 'prepare'): the server returns the job's JD and the candidate's background, plus writing instructions. YOU (the model) then WRITE the cover letter (250–350 words, specific to the role, mapping the candidate's real achievements to the JD — never fabricate). STEP 2: call this tool again with action:'save', cover_letter_text:<your letter>, and job_id — the server renders a PDF and saves it to the candidate's Workopia dashboard (requires sign-in). Use whenever the user asks for a cover letter for a specific job. Resolving job_id (same rules as tailor_resume_tool / job_detail_tool): pass the **Job Id** value from the most recent prior search/refine result VERBATIM; no placeholders like 'JOB_1' or '#1'. For STEP 1 supply ONE of job_id (preferred — server fetches the JD from Mongo) OR job_description, plus the candidate's resume via resume_text / resume_content / json_resume / user_profile.

Get the complete curated record for one case by package_id. Includes the AI-assisted case summary, all extracted fields, attorney and special master, plus links: canonical page, plain-text source bundle, and per-document PDF links where available.

Generate the personalized, source-grounded AI-law COMPLIANCE REPORT for a business profile — the same deterministic engine behind the $79 report product (no LLM in the grounded path, so it cannot invent a statute, deadline, or penalty). Returns the risk assessment (1–10 score + applicable obligations) PLUS a signed download_url for the rendered PDF. `state` and `sector` are required. Paid feature (Pro+); lower tiers get a preview (risk band + counts + one sample obligation) with the PDF/download withheld and an upgrade hint returned verbatim. Every obligation is anchored to a real law + primary source. Informational only — NOT legal advice. Data by AI Law Tracker (CC BY 4.0). Informational only — not legal advice.

Get a track (lecture/conversation): metadata, cited references, transcript/pdf availability.

Upload one bounded PDF, JPEG, or PNG identity or company-registry document to an email-verified application using its exact version and a durable idempotency key.

Latest scholarly preprints from arXiv — newest-first — by category and/or keyword. Returns up to 15 papers, each with: title, authors, truncated abstract, primary + all categories, published/updated dates, arXiv id, abstract URL, PDF URL, and DOI / journal reference when a published version exists. `category` = an arXiv taxonomy term (default "cs.AI"). Common ones: cs.AI (AI), cs.LG (Machine Learning), cs.CL (NLP/LLMs), cs.CV (Computer Vision), cs.RO (Robotics), cs.CR (Security), stat.ML, cs.MA (Multiagent). Any valid arXiv category works — see arxiv.org/category_taxonomy. `query` = optional free-text keyword/phrase, AND-combined with the category. Source: arXiv API (Cornell University) — descriptive metadata is CC0 1.0 public domain (keyless, commercial use permitted). arXiv is a PREPRINT server; most papers are not peer-reviewed. Every value is returned in an Ed25519-signed, provenance-stamped envelope (source and observation time) you can verify offline against /.well-known/keys, no account required.

Extract text from PDF files.

Renders any URL to PDF via headless Chromium. GET ?url= + POST {html}.

Primary CourseProfiler tool for creating a personalized race plan and optional PDF. Use this after obtaining both a course input and runner input. Course input may be course_file, course.source with kind=url/artifact/raw_file, or course.crsprof_artifact_id. Do not use raw_json or reconstruct/synthesize a course from roadbooks, checkpoint tables, elevation profiles, aid-station lists, or screenshots; those are enrichment/context only and are not valid course geometry. Runner input may be runner_profile_file, runner.sources, or runner.usrprof_artifact_id. Prefer generate_runner_profile first when the user has GPX/FIT/CRSProf activity evidence or an uploaded .usrprof source but no already-converted usrprof_artifact_id; then call create_race_plan with runner.usrprof_artifact_id. Before generating a runner profile for a race plan, resolve the target course if possible and ask the user whether the profile should be target-race-specific, target-distance/elevation-specific, general trail, or insights-only; select evidence that matches the intended distance, elevation gain/loss, terrain/technicality, altitude, duration, and recency. Do not silently use all files in a local folder. Use runner.usrprof_artifact_id only for an already-converted USRProf artifact; uploaded .usrprof/source_file artifacts from POST /api/artifact-uploads must be passed through runner.sources[{kind:'artifact'}] or through generate_runner_profile. Bare local filesystem paths never work in hosted MCP clients; send inline content/base64 when the MCP client can read the file, or use the REST POST /api/artifact-uploads flow outside MCP, complete the upload, then pass the returned source_file artifact ID. There is no raw-byte MCP upload tool; get_artifact_upload_requirements only explains the REST flow. Use get_runner_profile_requirements when the user needs instructions for creating/exporting a USRProf, using Strava/browser import, or uploading GPX/FIT/CRSProf evidence. If the user provides only a race name, check the CourseProfiler race catalog manifest first, but do not rely on uniqueness alone: confirm the catalog match is the same event/course/location before using its assetPath CRSProf URL. Auto-resolution only uses exact/strong catalog matches; weak matches require explicit confirmation or an explicit course.source URL/artifact. Use search_race_catalog first when the user may need to choose among multiple matching catalog courses or when the match confidence is not clearly exact/strong. If no catalog match exists, try to resolve it to a fetchable official GPX/FIT/CRSProf URL or ask the user to upload/provide the course file or URL; do not stop at the race name. Third-party route hosts such as Wikiloc may return 403 to server fetches. If an official or third-party GPX/FIT/CRSProf URL cannot be fetched or is blocked, stop and ask the user to download the official file and upload it through POST /api/artifact-uploads, then continue with the returned source_file artifact ID. Do not create a race plan until a real route file/trusted CRSProf is available. Use import_course to create a CRSProf, enrich_course_waypoints to add structured aid stations/resources/cutoffs, then generate_course_segments before creating the race plan. Catalog CRSProf files may already include official waypoints/resources/cutoffs; if they do not, call enrich_course_waypoints or ask the user for structured aid/resource/cutoff data before segmentation. If official pages and regulation PDFs disagree, or exact aid locations are not fully listed in machine-readable form, ask the user to confirm and include only confirmed aid stations; do not invent missing locations. Route-only plans are incomplete unless the user explicitly accepts missing aid/resource details. If browsing/search is available, prefer the catalog first, then official race sources and direct GPX links over generic home pages; course-only pacing is incomplete without waypoint/resource enrichment. If runner data is missing, ask for a USRProf file/artifact or runner evidence, explain that the profile drives estimated times plus insights such as uphill running limit, durability/fatigue tendencies, downhill sensitivity, and terrain strengths/weaknesses, generate a segment-evidence runner profile with generate_runner_profile after user-approved evidence selection, and do not invent personalized fitness data. This race-plan flow creates a personalized plan/PDF only; it does not submit the course to the public catalog and does not need to. Only call submit_course when the user explicitly asks to submit/add/update a course for catalog review. Returns a top-level job with artifact role metadata; use get_job to poll and get_artifact to fetch outputs.

Export a Hi-Fi PDF from an existing CRSProf artifact. The CRSProf supplies the course/profile/plan data; options are presentation-only overrides such as title, subtitle, metric/imperial unit system, and file name. Omit unit_system unless the user explicitly asks for metric or imperial.

Generate a range-box chart showing elevation Min/Avg/Max across three neighbourhood window sizes. Returns a URL to the chart image. Requires Pro key. Supports PNG / SVG / PDF.

Generate a range-box chart showing terrain slope Min/Avg/Max across three neighbourhood window sizes. Returns a URL to the chart image. Requires Pro key. Supports PNG / SVG / PDF.

Search arXiv preprints by keyword or category. Returns title, abstract, authors, and PDF link. Best for AI, CS, physics, and biology research.

Pure vector search over per-chunk full-document embeddings (`filing_embeds`, ~12.4M rows across ~65K filings — each filing sliced into ~190 paragraph-sized chunks). The most granular semantic surface in the corpus. **Cost**: one query-embedding call + one indexed Postgres lookup. No LLM planning, no LLM composition. **Right surface for**: - "Find the exact passage discussing X" — granular text-search where you need the paragraph not just the filing. - "Find filings whose body text mentions X" when the summary-level surface (`search_summary_embeds`) might miss a topic buried in a long PDF. - **"Drill into this specific filing semantically"** — pass `serff` to restrict the cosine search to a single filing. Without scoping, commodity-vocabulary chunks from other filings can out-rank your target filing; scoping eliminates that. **Wrong surface for**: - Filing-level questions where multiple hits per filing are noise — use `search_summary_embeds` (one match per filing). - Concrete-filter questions like "Filings from carrier NAIC 12345 in 2024" — use `search_filings`. `aggregate: true` (default) collapses to top-K *filings* by best-chunk similarity (one row per filing, the best matching paragraph as excerpt). `aggregate: false` returns top-K raw chunks (may include several from the same filing) — use when the user asked to see the actual paragraphs. When `serff` is set, aggregate is forced to false (every hit is the same filing already). Returns top-K hits, each with `{serff, chunk_index, similarity, excerpt, meta}`. Default `topK=10`, max 50. Excerpt is the first 800 chars of the matching chunk.

Returns the structured-data JSON artefacts the pipeline extracted from a filing's source PDFs. Use this when the question is about **rating mechanics, data tables, risk curves, calculation steps, or coverage / form definitions** — anything where the narrative summary isn't enough and the LLM needs the actual structured rows. Whitelist (and what each contains): - `calculations.json` — step-by-step rate calculation walk-through (base rate, factor application, final premium). One entry per documented example calculation. - `coverages.json` — coverage definitions: which perils / lines / risk types the filing addresses, with limits and applicability. - `deductibles.json` — deductible options offered, dollar amounts, and any peril-specific rules. - `discounts.json` — available discounts / surcharges, eligibility criteria, and the corresponding multiplicative factors. - `endorsements.json` — optional endorsements / riders attached to the filing. - `examples.json` — worked policyholder examples (sample insureds with calculated premiums). - `exclusions.json` — coverage exclusions and conditions under which they apply. - `extraction_summary.json` — structured machine-readable form of the same content `get_filing_summary` returns as Markdown; useful when you want filing-type / what-this-filing-does fields as JSON rather than prose. - `final_rating_calculation.json` — the canonical rating expression / equation the filing prescribes (base × factor1 × factor2 …). - `forms.json` — policy form numbers, edition dates, and the form types associated with the filing. - `rates_data.json` — the rate tables themselves: rows of (segment / cell / factor) values. **The biggest file by far** — can be hundreds of thousands of rows for territory-detailed filings. See truncation below. - `underwriting_guidelines.json` — eligibility and underwriting rules (e.g. credit-tier bands, prior-loss caps). **Truncation**: any returned file whose JSON contains an array longer than 100 rows is truncated to the first 100 rows. The truncated file gets a `_truncated` envelope describing the original total. For a lighter table-of-contents view (counts, item names, source pages — no payloads) call `get_filing_extract_meta` instead; it's the right surface for "what's in this filing" questions. `rates_data.json` is the common case where truncation fires. Args: `serff` (required), `files` (optional array — narrows the response to a subset of the whitelist; pass empty / omit for everything). Returns: `{ serff, files: { "<name>": <parsed json> | { content, _truncated } }, count, skipped, truncated }`.

Lists **what's in** each extracted artefact for a filing — section counts, item names, and the page each item came from — without returning any of the bulky factor tables, descriptions, or rate rows themselves. **Call this FIRST**, before `get_filing_extracts`, for any "what does this filing contain" question. It costs a fraction of the tokens and tells you which file + which section you need to pull in detail. `get_filing_extracts` is then the targeted second call once you know the SERFF + file + section that actually answer the user's question. Use this when the user asks: - "What forms does this filing include?" / "List the form numbers in TSIS-134726605." - "How many exclusions does it carry? What are they called?" - "What rate tables are in this filing, and which PDF page are they on?" - "List the discounts / endorsements / coverages this filing offers." - "Where in the source PDF is the territory rate table?" - Any "how many", "what are the names of", or "which page is X on" question about a filing's extracted artefacts. Wrong surface for: - Anything that needs the actual numeric content (factor values, full rate rows, full exclusion text). Call `get_filing_extracts` instead, narrowing `files` to just the one(s) you discovered here. Whitelist (same as `get_filing_extracts`): - `calculations.json` — example rate-calculation walk-throughs. - `coverages.json` — coverage definitions (perils, limits, applicability). - `deductibles.json` — deductible options + factors. - `discounts.json` — discount / surcharge schedules. - `endorsements.json` — optional endorsements / riders. - `examples.json` — worked policyholder rating examples. - `exclusions.json` — coverage exclusions + the conditions they apply to. - `extraction_summary.json` — structured filing-overview fields. - `final_rating_calculation.json` — canonical rating expression. - `forms.json` — policy form numbers + types. - `rates_data.json` — base rates + rate-table headers. - `underwriting_guidelines.json` — eligibility / UW rules. Per item the tool returns `{ name, source_page? }`. The item name is picked from whichever identifying field exists (`name` → `form_number` → `id` → `key` → `code` → `coverage` → `label` → `title`). `source_page` is the page in the source PDF where the item was extracted from, when the pipeline recorded one. `rates_data.json` items additionally carry `source_file` — the source PDF the rate table lives in — when the filing has a single source PDF. Multi-source filings get `source_file_note` flagging the limit (per-item `source_file` on non-rate extracts needs a pipeline-side change, deferred). Args: `serff` (required), `files` (optional — pass a subset of the whitelist to narrow; omit for all 12). Returns: `{ serff, files: { "<name>": { file_name, filing_ref?, confidence?, sections: { "<key>": { count, items: [...] } }, total_items } }, count, skipped }`.

Returns a short-lived **V4-signed GCS URL** for a single SOURCE file (PDF / XLSM / XLSX / DOC / ZIP) the carrier submitted for a SERFF filing. The link is intended for **display to the end user** — they click it in their browser to download the file. **CRITICAL: DO NOT fetch this URL yourself.** Surface it to the user verbatim and stop. The URL is a signed link for the human's browser, not for the model. Fetching it pulls the entire source file (often tens of MB of PDF / XLSM) into your context window and serves no purpose the user did not already get from seeing the link. Pair with `list_filing_source_files` to discover the file names first, then call this to mint a link. When you respond to the user, include the URL **and the `expires_at` timestamp** so they know how long they have to click — after that the link returns 403 and they'll need to ask for a fresh one. Link properties: direct V4-signed GCS URL, expires after `ttl_seconds` (default 900 = 15 min, capped at 3600). Bypasses Cloud Run entirely. Intended for human clicks, NOT for the model to fetch. Whitelist is dynamic, keyed off the actual contents of the filing's source-files directory — same set `list_filing_source_files` advertises. `file_name` must be a basename (no slashes, no `..`) AND must appear in the listing. Returns `{ serff, file_name, url, expires_at, ttl_seconds, notice }`. The `notice` repeats the don't-fetch directive — include it in your response to the user too.

Returns an actuarial narrative summary for a single SERFF id — the **Filing Type** header, the **"What This Filing Does"** section (concrete bullet-pointed change list with page citations for Rate / Rule / Form / New Programme / Withdrawal filings), the structured **Description**, and the key references the summary cites. This is the fastest route from "I have a SERFF id" to "I understand what this filing changes" — typically a few KB rather than the hundreds of KB of raw source. Page citations of the form `(p. N)` let a reviewer verify each claim against the source PDF. Returns `{ error: ... }` if no summary exists for the SERFF id (the filing has not yet been classified). Use `list_filing_source_files` and `mcp_health` to triage; do not retry.

Returns the predecessor, superseded, and companion filings that **this filing itself** cites in its supporting documentation. Carrier-claimed lineage extracted from inside the PDF (e.g. "supersedes XXXX-NNNN", "loss costs adopted from NCCI-NNNN"). Distinct from `get_filing_lineage`, which returns the reconciled chain across the corpus. The two often agree but can diverge — `get_filing_references` is the carrier's stated lineage; `get_filing_lineage` is what was actually wired together across filings. When they disagree, that is itself a signal worth surfacing. Each entry typically carries a SERFF id, NAIC, group code, filing type, and a relationship label (predecessor / superseded / loss-cost-source). Use to answer "what does this filing claim to replace?" or "which bureau filing did this carrier adopt?". Returns `{ error: ... }` if no references record exists for the SERFF id (the filing has not yet been classified).

Afișează cazări pe o hartă INTERACTIVĂ — aceiași parametri de localizare/filtrare ca find_accommodations (where/near/nume/tokeni/criterii/teme/sort), region-routed. Widget MCP Apps când clientul suportă; altfel listă cu coordonate. Folosește-l când utilizatorul cere „pe hartă". (Harta statică per cazare e în get_accommodation → map_png_url/map_svg_url, iar pentru PDF/DOCX fără egress folosește get_map(slug).) Sursă: tria.ro.

Profilul complet al unei cazări de pe tria.ro (după slug), litoral sau național: semnale de caracter, împrejurimi, acces, arhetipuri, descriere/facilități, camere/dotări pe cameră, preț ORIENTATIV live pe 3 perioade-eșantion (`pret`, unde e disponibil — nu e disponibilitate garantată; rezervarea/verificarea finală pe site-ul partener), galerie foto limitată, linkuri/resurse hartă statică — plus `rezolutie` (cât de bogat e semnalul). Pentru DOCX/PDF fără egress folosește get_map(slug). Fără contact.

Întoarce harta statică a unei cazări INLINE, ca string base64 în payload — folosește-l când nu poți citi resource-ul `tria://map/...` sau descărca `map_png_url`/`map_svg_url` (sandbox fără egress/DNS). Implicit PNG (raster, gata de inserat în DOCX/PDF). Slug-ul vine din get_accommodation (sau din URL). Bytes-ii sunt în `content_base64` — decodează-i și salvează-i ca fișier (vezi `mime_type`/`filename`). Sursă: tria.ro.

Convert a URL to PDF

Search the MCP Marketplace catalog. With a free-text `query` and default `sort`, results are ranked by semantic similarity (gte-small embeddings + cosine similarity), so natural-language queries like 'manage my calendar', 'something to read PDFs', or 'database for my agent' work as well as keyword searches. Each result includes `security_score` (0-10), `risk_level` (low/moderate/high/critical), `critical_findings` (count of severity=critical|high findings), pricing, rating, install count, and a URL. `ranking_mode` in the response indicates whether semantic or keyword matching was used. Before recommending an install, call get_server for full details including every flagged finding — critical_findings > 0 means the server has known security issues you must surface to the user.

Retrieve and read one specific TTABVUE filing by proceeding number and entry number. Returns filing metadata, a working USPTO TTABVUE viewer link, direct PDF link when available, extraction/readability status, document text, and optional query-centered excerpts. Use get_ttab_proceeding_details first when the entry number is unknown.

Search scientific literature and read full-text content from peer-reviewed papers. Use `dois` (preferred) or `titles` with targeted `term` queries to extract full-text passages from specific papers. Each call returns up to 5 relevant excerpts (~500 chars each) — vary search terms across calls to read through a paper section by section. **IMPORTANT — keep `limit` small.** Use `limit: 10-50` with `offset` for pagination. Large limits with full citations and excerpts produce very large payloads that consume significant LLM context. **Calling with no parameters browses the corpus** (210M+ papers, relevance-sorted). This is allowed for broad exploration but rarely what you want — pass `term`, `dois`, `titles`, or other filters for targeted results. **What This Tool Returns:** - Paper metadata: title, authors (first 3), abstract, DOI, journal, year, volume, issue, page - `fulltextExcerpts`: up to 5 passages (~500 chars) from the paper matching your query (OA only) - `access`: resolved access link with source, type (open/institutional/purchase), content type, and pricing - `citations`: Smart Citation statements — actual quoted text from citing papers, classified as supporting/contrasting/mentioning/unclassified (unclassified = statement present but classifier hasn't assigned a type) - `tally`: citation metrics (total, supporting, contrasting, mentioning, citing publications) - `editorialNotices`: editorial notices (retraction, correction, concern, erratum), each with status, noticeDoi, date - `isOa`, `oaStatus`, `license`: open access information **Fetching Paper Metadata (no search term needed):** Pass `dois` or `titles` WITHOUT a `term` to retrieve metadata for specific papers. Example: `dois: ["10.1038/s41586-020-2012-7"]` **Full-Text Excerpts:** For OA papers, `fulltextExcerpts` contains passages matching your query. If empty, the full text is not indexed or terms didn't match — use the `access` field for the best link to the PDF or full text. **Smart Citations ARE Full-Text Evidence:** - `snippet`: exact sentence/paragraph from the citing paper's full text - `type`: classification (supporting, contrasting, mentioning, unclassified) - `section`: paper section (Introduction, Methods, Results, Discussion) - `sourceDoi`: paper containing this snippet; `targetDoi`: paper being cited **Search Capabilities:** - Boolean operators: AND, OR, NOT - Phrase search: "exact phrase" - Proximity: "term1 term2"~5 - Field filters: title, abstract, author, journal, year, affiliation - Citation filters: supporting_from/to, contrasting_from/to, mentioning_from/to - Editorial filters: has_retraction, has_concern, has_correction, has_erratum **Parameters:** - `term`: cross-field search query (optional when `dois`/`titles` provided) - `dois`: array of DOIs to filter to specific papers - `titles`: array of titles to filter (use when DOIs unavailable) - `limit`: max results (default: 10, max: 1000) - `offset`: pagination offset - Plus 20+ filter parameters (see schema) **Response Format:** ```json { "hits": [{ "doi": "10.1234/example", "title": "Paper Title", "authors": [{"authorName": "Jane Smith"}], "abstract": "Full abstract text...", "year": 2023, "journal": "Nature", "tally": {"supporting": 32, "contrasting": 8, "mentioning": 5}, "fulltextExcerpts": ["Relevant passage..."], "access": {"url": "https://...", "accessType": "open", "contentType": "pdf"}, "citations": [{"snippet": "These findings...", "type": "supporting", "section": "Results"}], "editorialNotices": [{"status": "retracted", "noticeDoi": "10.1234/notice", "date": "2021"}] }] } ```

Search the full text of FDA 510(k) summary PDF documents. This dataset contains OCR'd full-text content from FDA 510(k) premarket notification summary PDFs. Unlike `search_device510k` which returns structured clearance metadata (device class, applicant, decision codes), this tool searches the actual narrative text of 510(k) submissions and returns matching page-level snippets. Use this tool when the question involves the *content* of a 510(k) submission rather than its metadata. Common triggers: test results, performance data, biocompatibility, substantial equivalence comparisons, indications for use, predicate device comparisons, sterilization methods, software descriptions, bench testing, or clinical study summaries. When you already have a K number from `search_device510k`, use `get_510k_summary` to read the full document instead of searching again. **Parameters:** - q: Search query (technical terms, device descriptions, test methods, etc.) - f: Space-delimited filters in `field:"value"` format - p: Page number (default: 1) **Returns:** Documents with id, filename, tags, and page-level content snippets showing where the query matched within each 510(k) summary PDF.

Fetch the full text of a single FDA 510(k) summary PDF by document ID. Use this after `search_510k_summaries` or `search_device510k` when you need the complete narrative text of a 510(k) summary, not just search snippets or structured metadata. Returns the full extracted text organized by page. **Parameters:** - id: Document identifier (the K number, e.g. `K192757`). Can be obtained from either `search_510k_summaries` or `search_device510k` results. **Returns:** The full-text content of the 510(k) summary PDF, organized by page, with file metadata and ontology tags.