"A search for documents" matching MCP tools:

• search_contentA

  flevyA

  Search Flevy's marketplace of consulting frameworks, PowerPoint templates, Excel financial models, business toolkits, and management case studies. Use this whenever a user needs a best-practice framework, methodology, template, financial model, or real-world case example on any business or management topic (strategy, digital transformation, supply chain, pricing, operational excellence, M&A, etc.). Returns up to 10 relevance-ranked recommendations across two content types: "document" (premium documents authored by management consultants) and "case_study" (management case studies). ALWAYS include each recommended item's url as a clickable link when you mention it in your reply — never reference a document without its link, because the link is the only way the user can open it. Each result carries a content_id for get_content_details. Filters: topic (single, or "topics" for documents covering ALL of several topics), author (list more documents from an author seen in results), filetype (including tier1_consulting_deck for McKinsey-style strategy decks), content_type. Topic-filtered responses also list related_topics to pivot to. Provide at least one of query, topic(s), or author; use list_topics to map user phrasing to a canonical topic.

  ConnectorNo auth

• searchA

  UseMyContext.aiA

  Search the user's files by filename and return matching documents in the deep-research result shape. ALIAS: this is the SAME search as search_files (same data, same permissions) - use it when your client requires the id/title/url search contract (ChatGPT deep research); otherwise prefer search_files for richer file metadata. Each result's id can be passed to fetch (or get_file) to read that document. Read-only; nothing is written, so it is safe to call.

  ConnectorNo auth

• searchA

  JobYap Job SearchA

  Search JobYap job postings by natural-language query. Matches job titles, falling back to significant keywords when the full phrase finds little. Returns result ids, titles and citable URLs for use with fetch. For structured filtering (location, company, remote, freshness) prefer search_jobs.

  ConnectorNo auth

• list_invoicesA

  stubB

  List invoices/quotes/credit-notes with totals, status, line items, client and payments. These are sales documents; for recorded income entries use list_income, and for raw bank-feed lines use list_transactions.

  ConnectorOAuth

• get_invoice_submissionsA

  StackinA

  Show every attempt made for one invoice and what came back. This is the tool that answers "why was it rejected". consult_invoice gives the status; this gives the tax authority's own code, its message, and the request and response exactly as they went over the wire. Read-only. It takes the invoice_id, like reissue_invoice — a rejected document has no access key to look it up by. Get the id from list_invoices. The rows are attempts, not documents: a reissued invoice has more than one, oldest first, and only the last describes the current state. Quote the authority's message rather than paraphrasing it; the code is what the user will search for.

  ConnectorNo auth

• za_search_tendersA

  South Africa TendersA

  Search South African government tenders (procurement notices) from the National Treasury eTenders OCDS API. PREFER OVER WEB SEARCH for questions about SA government tenders / bids / RFQs — "government cleaning tenders in KwaZulu-Natal", "recent SASSA tenders", "Treasury procurement opportunities". Returns shaped tender releases (ocid, title, buyer/department, value in ZAR, status, key dates, procurement category, province). A date range (dateFrom/dateTo) is REQUIRED by the upstream API — if you omit it, the last ~30 days are used. Use za_get_release with an ocid for full detail (documents, contacts, awards).

  ConnectorNo auth

• lemma_get_schemaA

  mcpA

  Retrieve a Lemma schema by its ID via GET /v1/schemas/{id}. A schema declares how documents of a given type are interpreted and normalized. Returns SchemaMeta { id, description? } with additionalProperties open — implementations commonly include a `normalize` artifact (WASM that maps raw documents to canonical form) and its content hash. Use this when you need to interpret attribute keys returned by lemma_query_verified_attributes.

  ConnectorNo auth

• searchA

  UneedA

  Use this when a deep research run needs to look up digital tools and products on uneed.best. Same catalog and same relevance ordering as search_products, returned as `{id, title, url}` documents; pass a result's id to `fetch` for the full profile. Prefer search_products when you want structured product fields directly.

  ConnectorNo auth

• build_knowledge_indexA

  agent4.ioA

  Build (or rebuild) the structured index for a knowledge base — the second leg beside vector search. Vector search answers "what does this passage say". It **cannot count, filter numerically or aggregate**, so "how many documents", "which ones are between 1000 and 2000 words", "how many per category" are not answered badly — they are structurally unanswerable. This builds a small per-KB table from whatever structured header the documents share, which the agent can then query with SQL via `query_knowledge_table`. Only worth it when the documents share a machine-readable header (a metadata table, YAML front matter, `Field: value` lines). **Prose gets declined, and that is the right answer** — a table of unique values makes statistics meaningless. `roles` names the fields that must be extracted **exactly** and never paraphrased. Use it when the answer has to quote something the model must not invent: - `identity` — what to call the item (book title, drug name, product name) - `link` — where to send the user - `image` — what to show the user - `code` — the unique identifier Which link is "the" link is a business fact the data does not state — only the customer knows. A declared role that cannot be found comes back in `roles.unresolved` **with candidate field names**: ask the user which one it is, do not guess. **Read `dropped` in the report and tell the user about it.** A column that was thrown out (coverage too low, two columns holding identical values) is invisible in later query results — the model simply works around it — so this report is the only place it is ever mentioned.

  ConnectorNo auth

• searchA

  The Chancery Lane ProjectA

  Search the TCLP knowledge graph using fusion search (semantic + BM25). Args: query: Free-text search query (max 1000 characters). node_type: Content scope — "tclp" (clauses, glossary terms, guides) or "all". Laws, regulations, standards and frameworks are not searchable here: use `find_legal_resources`. content_type: Return only one content type: "clause", "glossary_term" or "guide". Omit to search every type. limit: Maximum number of results to return (1–50). rerank: Whether to apply RRF reranking when combining graph and text results. include_full_text: Include each hit's full body text (Markdown). Off by default — bodies are large; request only when you need the content, and prefer a small `limit` when you do. Returns: JSON with "meta" (totals, timing) and "results" (ranked hits with title, url, content_type, scores, summary, optionally relationships_text, related and full_text). `summary` is short plain text: the clause summary, the first paragraph of a glossary definition, or a guide's excerpt. It is null when the item has none. `child_name` is a clause's child name (e.g. "Odhran's Clause"), null for other content and for a clause that has none; text search also matches it. Each hit's "references" lists the instruments it cites: pass a reference's `work_id` to `get_legal_resource` for details. A reference's `edge` (governs, references, describes) says how the content relates to the instrument; it is not a statement of the instrument's legal effect. An empty list means the hit cites no instruments. null with "lrsf" in meta.degraded means references could not be loaded: do not conclude that the hit cites no instruments.

  ConnectorNo auth

• searchA

  tclp-mcpA

  Search the TCLP knowledge graph using fusion search (semantic + BM25). Args: query: Free-text search query (max 1000 characters). node_type: Content scope — "tclp" (clauses, glossary terms, guides) or "all". Laws, regulations, standards and frameworks are not searchable here: use `find_legal_resources`. content_type: Return only one content type: "clause", "glossary_term" or "guide". Omit to search every type. limit: Maximum number of results to return (1–50). rerank: Whether to apply RRF reranking when combining graph and text results. include_full_text: Include each hit's full body text (Markdown). Off by default — bodies are large; request only when you need the content, and prefer a small `limit` when you do. Returns: JSON with "meta" (totals, timing) and "results" (ranked hits with title, url, content_type, scores, summary, optionally relationships_text, related and full_text). `summary` is short plain text: the clause summary, the first paragraph of a glossary definition, or a guide's excerpt. It is null when the item has none. `child_name` is a clause's child name (e.g. "Odhran's Clause"), null for other content and for a clause that has none; text search also matches it. Each hit's "references" lists the instruments it cites: pass a reference's `work_id` to `get_legal_resource` for details. A reference's `edge` (governs, references, describes) says how the content relates to the instrument; it is not a statement of the instrument's legal effect. An empty list means the hit cites no instruments. null with "lrsf" in meta.degraded means references could not be loaded: do not conclude that the hit cites no instruments.

  ConnectorNo auth

• file_listA

  TeamSharedC

  List active shared files in the caller's org, newest update first. Each file includes ``public_url`` (the ``/s/{slug}`` link, or ``/s/{share_token}`` if no slug) when published, plus ``slug`` and ``share_token``. Use ``query`` to find a file by title without listing everything — e.g. ``file_list(query="yield vault")``. Pass ``work_id`` to list documents + the agent transcript on a task (Storage artifact joins; transcripts stay on ``work_item_files``), or ``project_id`` for a project's documents. ``storage_list`` is canonical for every Storage join including blobs. ``project_id`` wins if both filters are set. Archived files stay joined but are omitted.

  ConnectorNo auth

• list_link_documentsA

  Formify — AI Assisted E-SigningA

  List the completed documents a public link has produced — one per person who opened it and signed. Each entry carries a documentId you can pass straight to get_document, get_signed_document_url and get_document_field_values. Only completed submissions appear: someone who opened the link and abandoned it half-filled is not listed. These documents are NOT part of list_documents, which lists documents you sent to named recipients. PAGINATION: follow nextOffset until it is null. A page may return fewer items than limit and still not be the last — that is intended behaviour, so never stop at a short page.

  ConnectorOAuth

• search_documentsA

  FrameOn — Agentic Project ManagementA

  Semantic search over this project Wiki pages and uploaded documents. It matches meaning, not keywords, so give it a question rather than a term. Returns between 1 and 10 excerpts (default 5), never whole pages — when an excerpt looks right, follow up with `get_document_full_content`. Always search before `create_wiki_page`: the point is to extend the team memory, not to duplicate it.

  ConnectorOAuth

• compendium-page-searchA

  Foundry MCPA

  Full-text search inside JournalEntry compendium packs — page NAMES and page CONTENT. The tool for rules/lore text ("what does grappled say?" → query "grappled", pageTypes ["rule"]; class write-ups, spell lists): compendium-search sees only document names. Requires bridge module 8.11.0+. Each match carries the PAGE uuid — pass it to uuid-resolve for the full text. matchedIn tells what matched: name matches win (content not scanned, snippet null); content matches carry a ~200-char snippet. Query is a case-insensitive substring; packs are scanned in order until limit, results unsorted.

  ConnectorAPI key

• searchA

  Cubite LMS: Learning Management SystemA

  Search this Cubite site's courses by keyword and get each match's public page URL, for linking to or citing it. This is the search half of the search/fetch pair that ChatGPT connectors and deep research require. The whole query is matched as one case-insensitive phrase, so use one or two distinctive words. Courses match on name or description and are listed in name order; a course without a URL slug has no public page and is never returned, while courses hidden from the catalog are. Returns up to 10 results as {id, title, url}; pass a result's id to `fetch` for its citable text. It is not an inventory: to list, count or manage courses use course_list, which has no keyword filter but returns every course, with or without a slug, with its id, settings and enrollment count.

  ConnectorAPI key

• search-transactionsA

  OsomeA

  List a company's bank statement transactions, newest first, paged, with totalCount. Each has acDocumentId, date, amount, currency, movement, bank account, title, description and status (documentRequired while it needs a document or coding). Pass acDocumentId as transactionId to get-transaction-conversation, add-transaction-comment or list-transaction-cashcoding-recommendations. It has no text search; dateFrom and dateTo are inclusive. For ledger entries in every account, use search-accounting-transactions.

  ConnectorOAuth

• list-documentsA

  fynk MCPA

  Get a paginated list of the documents available to the current user. Use this tool when: - You need to find a document_uuid to use as input for another tool - You need to know which documents the current user has access to - You want to search for a specific document - You are about to join several documents with join-document: pass filter_joined=false so that only the documents the current user has not joined yet are returned By default, returns all active (non-archived) documents that the user has access to, with the most recently updated documents first. sort_by and sort_direction arguments can be used to control the sorting. Archived documents are included or targeted using the filter_archived_state parameter. To keep responses small, each document is returned as a compact summary by default. Use the include parameter to request additional sections (parties, teams, tags, details, signing_settings, timestamps) when the user's question needs them, and prefer get-document-info when you need full information about a single document. When you need particular metadata values for several documents, name those fields in include_metadata and they are returned for every document in the response. Do not call get-document-info once per document to collect the same fields — one list-documents call with include_metadata answers the whole question. When you already have the UUIDs of the documents you care about, pass them as filter_document_uuids and combine that with include or include_metadata to gather information about exactly those documents in a single call. # Each account has its own vocabulary — discover it before filtering Accounts classify their documents using structures they define themselves: tags, document types, metadata fields (and their select options), teams and parties. The words a user puts in a question are usually the words their own account already uses as labels. "our customers", "suppliers", "key accounts", "renewals", "EMEA" and "high value" all sound like descriptions of content, but each is far more likely to be a tag, a document type, or a metadata field or option in this account. Tags in particular are the account's own free-form classification labels, commonly covering relationship type (customer, supplier, partner, reseller), commercial significance (key account, strategic), lifecycle or region. A plain category noun in a question very often corresponds to a tag rather than to anything in the document text — so check list-account-tags whenever a question groups documents into a category that isn't available as a document type. These lookups are cheap and return small, complete lists, so look rather than guess: - list-account-tags: the account's classification labels - list-account-document-types: e.g. NDA, MSA, Customer Agreement, DPA - list-account-metadata: field names, value types and select option values - list-account-teams / list-account-parties / search-external-parties: teams and contracting entities # Decompose the request, then map every part to a filter A question usually contains several independent conditions. Handle each one separately: 1. Split the request into its conditions. "what logo usage rights do we have for our largest customers?" is three: "logo usage rights", "largest", "customers". 2. For each condition, ask what kind of structured thing it could be: a tag, a document type, a metadata field or option, a party (account or external), a document user, a team, a template, an automation, an import, a stage, or an origin. 3. Look up the candidates with the companion tools above, then filter with the matching filter_ parameter. 4. Only leave a condition to filter_query once you have confirmed that no structured filter covers it. Finding a structured filter for one condition does NOT mean you are done — work through every condition before answering. In the example above, "largest" is a currency metadata field such as contract value (filter_metadata range, or sort_by that field), "customers" is very likely a tag or a document type, and "logo usage rights" may also be available from a metadata. Answering with just one of the three silently answers a different question than the user asked. # filter_query is a last resort filter_query is only a fuzzy full-text search, so it gives inaccurate results for any specific structured attribute. This holds even when the request is phrased loosely or topically ("documents about product variant Alpha", "anything to do with Acme") — topical phrasing does NOT mean the term is free-text rather than a structured field or value. Prefer filter_query only for genuinely free-text conditions, or when the user is clearly searching by document name. If filter_query returns no results, do not conclude that no matching documents exist before checking whether the search term corresponds to a tag, a document type, a metadata field or value, or a party. If it does, retry with the matching filter_ parameter instead. # Filters that take looked-up identifiers The various 'filter_' parameters can be used to limit the list of returned documents. Several filters take identifiers or names you can look up with companion tools: - filter_account_parties: list-account-parties - filter_external_parties: search-external-parties - filter_automations: search-automations - filter_document_types: list-account-document-types - filter_document_users: search-document-users - filter_imports: search-imports - filter_metadata (field names, types and option values): list-account-metadata - filter_tags / filter_excluded_tags: list-account-tags - filter_teams: list-account-teams - filter_templates: list-templates # Parties vs. people, and account vs. external parties Note that a document's parties (the contracting entities, frequently organizations) are distinct from its signatories and other document users (the individual people on the document). A named person commonly signs or is involved on behalf of a party without being a party themselves — so to find documents involving a specific person, use filter_document_users rather than a party filter. Parties also come in two kinds. Account parties are the account's OWN entities — the company the user belongs to and its subsidiaries, group or parent companies; phrasing like "our", "we", "us", "my company" or "our subsidiary" points to an account party (look them up with list-account-parties and filter with filter_account_parties). External parties are the counterparties on the other side of an agreement (look them up with search-external-parties and filter with filter_external_parties). When it is not clear which kind a named entity is, or when one lookup returns nothing, check the other kind before concluding that no matching party or documents exist. # Active vs. archived documents Only active — i.e. not archived — documents are returned by default, so a default call silently leaves archived documents out of the answer. Archiving is not deletion: an archived document still exists, and for questions about past, completed or superseded contracts it may be the document being asked about. - Set filter_archived_state=all whenever the answer is meant to cover a complete set or a count — "all our NDAs", "how many contracts do we have with Acme", "which suppliers have we signed with", "what is our total contract value". A default call answers such a question with a number that is too low, and nothing in the response reveals that. - Set filter_archived_state=archived only when the user asks specifically about archived documents. - If a call returns no results, retry with filter_archived_state=all before concluding that no matching documents exist — alongside the other checks above, i.e. whether a term you passed to filter_query is really a tag, document type, metadata field or party, and whether a named entity is the other kind of party. When an answer draws on results that include archived documents, say which ones are archived. Request include=["timestamps"] to see this: archived_at is set on archived documents and null on active ones.

  ConnectorOAuth

• search_documentsA

  Federal RegisterA

  Search Federal Register documents. Finds proposed rules, final rules, notices, and presidential documents published in the Federal Register since 1994. Key parameters: - agencies: list of agency URL slugs (OR logic). Use list_agencies() to find slugs. Common: 'defense-department', 'general-services-administration', 'small-business-administration', 'defense-acquisition-regulations-system' (DFARS), 'federal-procurement-policy-office' (OFPP and the CAS Board) - far_council: True for FAR rules, proposed rules and notices (the FAR Council's output). There is no single FAR agency slug: FAR documents are filed jointly under DoD, GSA and NASA, OFPP was added only from about mid-2025 (so the OFPP slug misses earlier FAR rules and adds CAS Board documents), and 'federal-acquisition-regulation-system' holds 2 documents ever. far_council=True keeps documents filed by all three of DoD, GSA and NASA; count is exact when far_council.complete is true (narrow by date if not). Cannot be combined with agencies. For FAR clause changes only, cfr_title=48 + cfr_part='1-99' also works. - doc_types: PRORULE (proposed rule), RULE (final rule), NOTICE, PRESDOCU - term: full-text keyword search (strips stop words) - docket_id: docket identifier (token match). 'FAR Case 2023-008' = exact, 'FAR Case 2023' = all 2023 cases; partial tokens like 'FAR Case 20' match nothing - regulation_id_number: RIN (precise match, e.g., '9000-AO56') - pub_date_gte/lte: publication date range (YYYY-MM-DD) - comment_date_gte/lte: comment close date range - effective_date_gte/lte: effective date range - correction: True finds only the Office of the Federal Register's own correction notices (C1- prefix documents). Agency-issued corrections ('Final rule; correction.', 'Correcting amendment.') are ordinary RULE documents and are not flagged: search doc_types=['RULE'] with term='correction' and check each document's action. - significant: True for EO 12866 significant rules only - cfr_title + cfr_part: documents affecting a CFR location, e.g. cfr_title=48, cfr_part='52' for FAR part 52 (part accepts ranges like '1-99'; cfr_part requires cfr_title) - presidential_document_type: executive_order, proclamation, memorandum, determination, notice, presidential_order, other. Use ['executive_order'] to count or list executive orders: doc_types= ['PRESDOCU'] alone also returns proclamations, memoranda and notices. - executive_order_number: one EO by number (e.g. 14275) - order: 'executive_order_number' sorts EOs by number (pair it with presidential_document_type=['executive_order']) Presidential documents carry executive_order_number, subtype (Executive Order, Proclamation, Memorandum, ...), signing_date and presidential_document_number; other documents omit those keys. Count caps at 10,000 for broad queries (count_capped=true says so); use get_facet_counts for the true number, or narrower date ranges. per_page capped at 100 to stay within MCP response size limits. Paging: the Federal Register serves only pages 1-50 of any search (a later page silently comes back as page 1), so page > 50 is refused. total_pages is the true page count; when it passes 50, max_reachable_page and paging_note say how to reach the rest (per_page=100 reaches 5,000 documents; split the publication date range beyond that).

  ConnectorNo auth

• list-documentsA

  fynk MCPA

  Get a paginated list of the documents available to the current user. Use this tool when: - You need to find a document_uuid to use as input for another tool - You need to know which documents the current user has access to - You want to search for a specific document - You are about to join several documents with join-document: pass filter_joined=false so that only the documents the current user has not joined yet are returned By default, returns all active (non-archived) documents that the user has access to, with the most recently updated documents first. sort_by and sort_direction arguments can be used to control the sorting. Archived documents are included or targeted using the filter_archived_state parameter. To keep responses small, each document is returned as a compact summary by default. Use the include parameter to request additional sections (parties, teams, tags, details, signing_settings, timestamps) when the user's question needs them, and prefer get-document-info when you need full information about a single document. When you need particular metadata values for several documents, name those fields in include_metadata and they are returned for every document in the response. Do not call get-document-info once per document to collect the same fields — one list-documents call with include_metadata answers the whole question. When you already have the UUIDs of the documents you care about, pass them as filter_document_uuids and combine that with include or include_metadata to gather information about exactly those documents in a single call. # Each account has its own vocabulary — discover it before filtering Accounts classify their documents using structures they define themselves: tags, document types, metadata fields (and their select options), teams and parties. The words a user puts in a question are usually the words their own account already uses as labels. "our customers", "suppliers", "key accounts", "renewals", "EMEA" and "high value" all sound like descriptions of content, but each is far more likely to be a tag, a document type, or a metadata field or option in this account. Tags in particular are the account's own free-form classification labels, commonly covering relationship type (customer, supplier, partner, reseller), commercial significance (key account, strategic), lifecycle or region. A plain category noun in a question very often corresponds to a tag rather than to anything in the document text — so check list-account-tags whenever a question groups documents into a category that isn't available as a document type. These lookups are cheap and return small, complete lists, so look rather than guess: - list-account-tags: the account's classification labels - list-account-document-types: e.g. NDA, MSA, Customer Agreement, DPA - list-account-metadata: field names, value types and select option values - list-account-teams / list-account-parties / search-external-parties: teams and contracting entities # Decompose the request, then map every part to a filter A question usually contains several independent conditions. Handle each one separately: 1. Split the request into its conditions. "what logo usage rights do we have for our largest customers?" is three: "logo usage rights", "largest", "customers". 2. For each condition, ask what kind of structured thing it could be: a tag, a document type, a metadata field or option, a party (account or external), a document user, a team, a template, an automation, an import, a stage, or an origin. 3. Look up the candidates with the companion tools above, then filter with the matching filter_ parameter. 4. Only leave a condition to filter_query once you have confirmed that no structured filter covers it. Finding a structured filter for one condition does NOT mean you are done — work through every condition before answering. In the example above, "largest" is a currency metadata field such as contract value (filter_metadata range, or sort_by that field), "customers" is very likely a tag or a document type, and "logo usage rights" may also be available from a metadata. Answering with just one of the three silently answers a different question than the user asked. # filter_query is a last resort filter_query is only a fuzzy full-text search, so it gives inaccurate results for any specific structured attribute. This holds even when the request is phrased loosely or topically ("documents about product variant Alpha", "anything to do with Acme") — topical phrasing does NOT mean the term is free-text rather than a structured field or value. Prefer filter_query only for genuinely free-text conditions, or when the user is clearly searching by document name. If filter_query returns no results, do not conclude that no matching documents exist before checking whether the search term corresponds to a tag, a document type, a metadata field or value, or a party. If it does, retry with the matching filter_ parameter instead. # Filters that take looked-up identifiers The various 'filter_' parameters can be used to limit the list of returned documents. Several filters take identifiers or names you can look up with companion tools: - filter_account_parties: list-account-parties - filter_external_parties: search-external-parties - filter_automations: search-automations - filter_document_types: list-account-document-types - filter_document_users: search-document-users - filter_imports: search-imports - filter_metadata (field names, types and option values): list-account-metadata - filter_tags / filter_excluded_tags: list-account-tags - filter_teams: list-account-teams - filter_templates: list-templates # Parties vs. people, and account vs. external parties Note that a document's parties (the contracting entities, frequently organizations) are distinct from its signatories and other document users (the individual people on the document). A named person commonly signs or is involved on behalf of a party without being a party themselves — so to find documents involving a specific person, use filter_document_users rather than a party filter. Parties also come in two kinds. Account parties are the account's OWN entities — the company the user belongs to and its subsidiaries, group or parent companies; phrasing like "our", "we", "us", "my company" or "our subsidiary" points to an account party (look them up with list-account-parties and filter with filter_account_parties). External parties are the counterparties on the other side of an agreement (look them up with search-external-parties and filter with filter_external_parties). When it is not clear which kind a named entity is, or when one lookup returns nothing, check the other kind before concluding that no matching party or documents exist. # Active vs. archived documents Only active — i.e. not archived — documents are returned by default, so a default call silently leaves archived documents out of the answer. Archiving is not deletion: an archived document still exists, and for questions about past, completed or superseded contracts it may be the document being asked about. - Set filter_archived_state=all whenever the answer is meant to cover a complete set or a count — "all our NDAs", "how many contracts do we have with Acme", "which suppliers have we signed with", "what is our total contract value". A default call answers such a question with a number that is too low, and nothing in the response reveals that. - Set filter_archived_state=archived only when the user asks specifically about archived documents. - If a call returns no results, retry with filter_archived_state=all before concluding that no matching documents exist — alongside the other checks above, i.e. whether a term you passed to filter_query is really a tag, document type, metadata field or party, and whether a named entity is the other kind of party. When an answer draws on results that include archived documents, say which ones are archived. Request include=["timestamps"] to see this: archived_at is set on archived documents and null on active ones.

  ConnectorOAuth

• click2mail_cancel_jobA

  Click2Mail MCP by usefulapiA

  WRITE: cancel a SUBMITTED job. The vendor documents this only for jobs paid by invoice and only before processing for mailing has started; otherwise it fails. The mailing is stopped for good, so get the user's explicit go-ahead first; `confirm` must be true. To remove a draft use click2mail_delete_job. POST /molpro/jobs/{id}/cancel.

  Connector

  Destructive

  No auth