"DOI" matching MCP tools:

• update_collection

  Scite

  Update a DOI-list Collection the signed-in user can edit. Partial update: only the fields you supply change; omitted fields keep their current values. Omitting `dois` leaves the DOI list untouched; supplying `dois` replaces it (unknown DOIs are dropped and surfaced via `unmatchedDoiCount`). Requires EDITOR or ADMIN access. Only DOI-list Collections can be updated here — saved-search Collections are managed in the scite web app. **Parameters:** - slug: The Collection slug (required). - name: New name (optional). - description: New description (optional). - dois: Replacement DOI list (optional; omit to leave DOIs unchanged). - is_public: New public flag (optional). **Returns:** The updated Collection with id, slug, name, accessType, and DOI counts.

  Connector

• search_authorities

  What Do They Know?

  Search WhatDoTheyKnow public authorities by name. Returns up to `limit` authorities whose name or short_name contains `query` (case-insensitive). Use the `slug` field with authority_json or build_request_url as the next step. Example: search_authorities("Liverpool") → slug "liverpool_city_council" Then: authority_json with that slug, or build_request_url with it.

  Connector

• pubmed_convert_ids

  pubmed-mcp-server

  Convert between article identifiers (DOI, PMID, PMCID). Accepts up to 50 IDs of a single type per request. Only resolves articles indexed in PubMed Central — for articles not in PMC, use pubmed_search_articles instead.

  Connector

• openfinance_list_transactions

  Banco do Brasil MCP

  Returns transactions for a bank account (BANK or CREDIT type). For CREDIT (credit card) accounts, this is the ONLY way to get itemized transactions (purchases, subscriptions, etc.). Each credit card transaction MAY carry `creditCardMetadata.billId` pointing at a bill from openfinance_list_credit_card_bills, but this is a per-connector HINT, not authoritative: some connectors (e.g. Nubank) populate it sparsely (many transactions and installments arrive with no billId) or inconsistently (the same payment tagged to more than one bill). Do NOT reconstruct a bill's total by summing transactions by billId — the bill's own `totalAmount` from openfinance_list_credit_card_bills is the source of truth. CREDIT PENDING vs POSTED varies by connector: where the bank exposes future-dated `status:'PENDING'` installments, those represent the OPEN bill plus future bills (future months); where it does NOT, only the last closed bill's POSTED items appear until ~closing. Same query, different coverage per bank (upstream). To get a standardized open-bill total / total debt regardless, use openfinance_list_credit_card_bills (`open_bill` / `total_pending_debt`). Supports from/to date filters (ISO YYYY-MM-DD) and an optional keyword filter via `search_queries` (case- and accent-insensitive substring match against description and merchant name, OR semantics across multiple terms). When `search_queries` is set the tool aggregates up to 5000 transactions within from/to before filtering — narrow from/to if `truncated:true` is returned. PAGINATION: OMIT both `page` and `page_size` (the default) to get ALL transactions in the from/to range in one call — the tool auto-paginates the upstream and returns them under a single logical page (`page:1`, `totalPages:1`), up to a 5000 ceiling (`truncated:true` + warning if exceeded, then narrow from/to). Passing `page` and/or `page_size` switches to MANUAL pagination: you get one page (`page_size` items, default 50, max 500; `page` defaults to 1) with the REAL `total`/`totalPages`, so `page_size:5` alone returns the first 5 with `totalPages` telling you how many pages remain. On upstream errors, returns { total:0, results:[], warning, error } instead of throwing. `detail` controls how much per-row data you get (default `'compact'` = slim, cheap). Use `detail:'rich'` to enrich each row (when the bank connector provides it) with `merchantInfo` (estabelecimento: businessName/razão social, cnpj, cnae, category — useful for auto-classifying spending) and extra `creditCardMetadata` fields: `billId` (a per-connector HINT toward the transaction's bill — sparse/inconsistent on some connectors like Nubank, so do NOT sum by it to get a bill total; use the bill's `totalAmount` instead), `purchaseDate`, `payeeMCC`, `feeType`/`feeTypeAdditionalInfo`, `otherCreditsType`/`otherCreditsAdditionalInfo`. Use `detail:'raw'` to get the FULL untouched Pluggy transaction object (everything Pluggy returns, un-normalized — heaviest, for when you need a field we don't project). 'rich'/'raw' add tokens per row and coverage varies by bank/Open Finance, so keep the default for normal listings. For the card's statement closing/due dates use openfinance_list_accounts (`creditData.balanceCloseDate` / `balanceDueDate`). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH account/bank these transactions belong to. When more than one bank is connected, ALWAYS cross-check the echo against the account you intended to query and name the bank when presenting results — never attribute one bank's transactions to another. If total is 0 for a CREDIT account, check the connection health via openfinance_get_item_status — `statusDetail.creditCards.isUpdated: false` means the credit card sync failed and a force sync (openfinance_force_sync) or reconnection may be needed. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a connected bank: transactions may come back incomplete or wrong until the provider recovers, and reconnecting does not fix it. Bulk support: accepts account_ids for batched execution.

  Connector

• create_collection

  Scite

  Create a new Collection owned by the signed-in user. Use this to start a Collection from a list of DOIs the user wants to group, track, and analyze together. The caller becomes the Collection ADMIN. The returned `slug` identifies the Collection for `get_collection`, `update_collection`, `add_dois_to_collection`, and the other Collection tools. **DOI validation.** Provided DOIs are validated and resolved against scite; unknown DOIs are dropped and surfaced via the `unmatchedDoiCount` in the response. An empty `dois` list creates an empty Collection the user can add to later. **Scope.** This tool creates DOI-list Collections. Collections backed by a saved search query are created in the scite web app, not via MCP. **Parameters:** - name: Collection name (required). - description: Optional free-text description. - dois: Optional list of DOI strings to seed the Collection. - is_public: If true, anyone with the slug can view the Collection (default: false). **Returns:** The created Collection with id, slug, name, description, isPublic, doiQueryType, accessType, and DOI counts.

  Connector

• add_dois_to_collection

  Scite

  Add DOIs to a Collection. Works on both DOI-list and saved-search Collections. Requires EDITOR or ADMIN access. For a DOI-list Collection the DOIs are added to the list. For a saved-search Collection they are force-included (added to the manual include list) so they appear even if the search would not return them. DOIs already present are ignored. Use `create_collection` to make a new Collection or `remove_dois_from_collection` to take DOIs out. **Parameters:** - slug: The Collection slug (required). - dois: List of DOI strings to add (required, non-empty). **Returns:** The updated Collection with id, slug, name, and DOI counts.

  Connector

• remove_dois_from_collection

  Scite

  Remove DOIs from a Collection. Works on both DOI-list and saved-search Collections. Requires EDITOR or ADMIN access. For a DOI-list Collection the DOIs are dropped from the list. For a saved-search Collection they are excluded (added to the exclude list) so they no longer appear even if the search would return them. DOIs not present are ignored. This removes papers from the Collection; it does not delete the Collection itself (use `delete_collection` for that). **Parameters:** - slug: The Collection slug (required). - dois: List of DOI strings to remove (required, non-empty). **Returns:** The updated Collection with id, slug, name, and DOI counts.

  Connector

• biobtree_map

  BioBTree

  Map identifiers between databases. SYNTAX: biobtree_map(terms="ID", chain=">>source>>target") - Chain MUST start with ">>" - Source MUST match input ID type ID TYPE → SOURCE: - ENSG* → >>ensembl - P*/Q*/O* → >>uniprot - CHEMBL* → >>chembl_molecule - GO:* → >>go - MONDO:* → >>mondo - HP:* → >>hpo - HGNC:* or gene symbols → >>hgnc SOME DRUG EXPLORATION PATHS: - >>chembl_molecule>>chembl_target>>uniprot (drug targets) - >>pubchem>>pubchem_activity>>uniprot (bioactivity) - >>gtopdb_ligand>>gtopdb_interaction>>gtopdb>>uniprot (curated pharmacology with affinity data) - >>ensembl>>reactome>>chebi (pathway chemicals - when no direct targets) - Discover more via entry xrefs + EDGES WARNING - GO terms with high xref_count (>100): - Don't map GO → proteins → drugs (too many results) - Instead: search drug class for condition → verify targets this GO term DISEASE GENE PATTERNS: - >>mondo>>gencc>>hgnc (curated) - >>mondo>>clinvar>>hgnc (variant-based) - >>hgnc>>clingen_gene_validity (ClinGen evidence tier), >>hgnc>>clingen_dosage (haploinsufficiency), >>hgnc>>clingen_variant>>clinvar (ACMG, then dbsnp) CANCER / CELL LINE: - >>hgnc>>intogen (cancer driver gene?), >>hgnc>>civic (clinical variant interpretations) - >>uniprot>>cellosaurus (cell lines for a protein/gene) - >>hgnc>>depmap (CRISPR essentiality / target tractability), >>hgnc>>entrez>>depmap_dependency>>cellosaurus (which lines depend on the gene) GENE FUNCTION / LITERATURE: - >>entrez>>generif (cited one-line functional claims; >>generif>>pubmed for citations) DISEASE → DRUG PATTERNS: - >>mesh>>chembl_molecule (MeSH disease/condition → drugs with indications) - >>mondo>>clinical_trials>>chembl_molecule (disease → trial drugs) DISCOVERY APPROACH: - Use biobtree_entry to see xrefs (what's connected) - Use EDGES above to see where each dataset leads - Build chains based on what connections exist for YOUR entity RETURNS: mapped identifiers with dataset and name EDGES (what connects to what): ensembl: uniprot, go, transcript, exon, ortholog, paralog, hgnc, entrez, refseq, bgee, gwas, gencc, antibody, scxa, civic, intogen, hpa, hpa_antibody, pharmgkb_var_annotation, chembl_mechanism, ncrna_disease, ncrna_interaction, ncrna_drug, alliance_disease, gnomad_constraint, drugcentral, panelapp_gene hgnc: ensembl, uniprot, entrez, gencc, pharmgkb_gene, msigdb, clinvar, mim, refseq, alphafold, collectri, gwas, hpo, cellphonedb, civic, intogen, cellosaurus, clingen_gene_validity, clingen_dosage, clingen_variant, depmap, hpa, pharmgkb_var_annotation, chembl_mechanism, ncrna_disease, ncrna_interaction, ncrna_drug, alliance_disease, drugcentral, panelapp_gene, gnomad_constraint, mavedb entrez: ensembl, uniprot, refseq, go, biogrid, pubchem_activity, ctd_gene_interaction, dbsnp, civic, intogen, clingen_dosage, generif, depmap, depmap_dependency, hpa, pharmgkb_var_annotation, orthologentrez, relatedentrez, neighborentrez, mgi, rgd, zfin, wormbase, xenbase, sgd, flybase, gnomad_constraint, drugcentral orthologentrez: entrez # cross-species gene orthologs (NCBI gene_orthologs). >>entrez>>orthologentrez gives ortholog genes (filter species via taxonomy); reliable from model-organism genes (human-gene side currently incomplete) relatedentrez: entrez # related genes (bidirectional): NCBI gene_group (functional gene/pseudogene/readthrough/region) + HGNC gene-family co-members neighborentrez: entrez # genomic neighbors (left/right/overlapping); edge carries distance + side, neighbor strand/position in attrs; filter to genes via [type!="biological-region"] gnomad_constraint: ensembl, entrez, hgnc, transcript # gene LoF constraint (pLI/LOEUF/oe_lof); reach via >>ensembl>>gnomad_constraint drugcentral: chembl_molecule, pubchem, uniprot, ensembl, hgnc, entrez # approved drugs -> targets/MOA + FDA/EMA/PMDA approval; reach via name/INN/InChIKey or compound (chembl_molecule/pubchem >> drugcentral) refseq: ensembl, entrez, taxonomy, ccds, uniprot, mirdb mirdb: refseq transcript: ensembl, exon, ufeature, alphamissense, civic_variant, gnomad_constraint, mavedb uniprot: ensembl, alphafold, interpro, pfam, pdb, ufeature, intact, string, string_interaction, biogrid, biogrid_interaction, chembl_target, go, reactome, rhea, swisslipids, bindingdb, antibody, pubchem_activity, cellphonedb, jaspar, signor, diamond_similarity, esm2_similarity, alphamissense, cellosaurus, hpa, chembl_mechanism, ncrna_interaction, drugcentral, mavedb alphafold: uniprot interpro: uniprot, go, interproparent, interprochild chembl_molecule: mesh, chembl_activity, chembl_target, pubchem, chebi, clinical_trials, chembl_moleculeparent, chembl_moleculechild, chembl_mechanism, ncrna_drug, faers, drugcentral # parent=anhydrous/parent form, child=salt forms chembl_activity: chembl_molecule, chembl_assay, bao chembl_assay: chembl_activity, chembl_target, chembl_document, bao chembl_target: chembl_assay, uniprot, chembl_molecule, chembl_mechanism chembl_mechanism: chembl_molecule, chembl_target, uniprot, hgnc, ensembl # curated drug mechanism-of-action (incl. RNA therapeutics): drug >> chembl_mechanism, target/gene >> chembl_mechanism pubchem: chembl_molecule, chebi, hmdb, pubchem_activity, pubmed, patent_compound, bindingdb, ctd, pharmgkb, ncrna_drug, faers, drugcentral faers: chembl_molecule, pubchem, faers_reaction # openFDA FAERS drug->adverse-event; faers (per-drug master) -> faers_reaction children (PRR), reach via drug name or compound. NOTE co-occurrence not causation faers_reaction: faers # one per (drug,reaction): report_count, prr, serious_count, outcome; most-reported first pubchem_activity: pubchem, ensembl, uniprot chebi: pubchem, rhea, intact swisslipids: uniprot, go, chebi, uberon, cl lipidmaps: chebi, pubchem dbsnp: entrez, clinvar, pharmgkb_variant, alphamissense, spliceai, pharmgkb_var_annotation clinvar: hgnc, mondo, hpo, dbsnp, orphanet, civic_variant, cellosaurus, clingen_variant alphamissense: uniprot, transcript mavedb: uniprot, hgnc, ensembl, transcript # deep-mutational-scanning functional variant scores (ACMG PS3/BS3); reach via gene/protein >> mavedb; per-variant score + hgvs_pro + license # VARIANT-EFFECT SCORES — look up by the variant's OWN key with biobtree_entry(dataset=..), NOT via >>chains: # conservation key "chr:pos" (GRCh38) per-position phyloP / GERP / phastCons (also covers non-missense/splice positions) # gnomad_variant key "chr:pos:ref:alt" (GRCh38) gnomAD v4.1 genomes allele freq (af, grpmax, per-ancestry); also xrefs dbsnp # revel key "chr:pos:ref:alt" (GRCh38) REVEL ensemble missense pathogenicity (0-1, higher = pathogenic) # saprot key "uniprot:protein_variant" SaProt protein-LM variant effect (LLR <=0, lower = more damaging), e.g. P01116:G12D gwas: gwas_study, efo, dbsnp, hgnc, mondo gwas_study: gwas, efo, mondo mondo: gencc, clinvar, efo, mesh, hpo, clinical_trials, antibody, cellxgene, cellxgene_celltype, orphanet, mondoparent, mondochild, gwas, gwas_study, civic, intogen, cellosaurus, doid, mim, ncit, umls, medgen, gard, sctid, icd9, icd10cm, icd10who, icd11, nando, meddra, nord, uberon, ncrna_disease, panelapp_gene # disease cross-refs + disease_has_location anatomy, from the Mondo OBO doid: mondo, alliance_disease, doidparent, doidchild # Disease Ontology (now a full ontology w/ hierarchy); reach MONDO + its disease graph via the mondo<->doid bridge alliance_disease: hgnc, mgi, rgd, zfin, sgd, wormbase, flybase, xenbase, doid, pubmed # cross-species + human gene->disease (Alliance of Genome Resources); gene >> alliance_disease >> doid, or doid >> alliance_disease >> mgi/rgd/... for model-organism genes alliance_phenotype: mgi, rgd, wormbase, xenbase, mp, wbphenotype, xpo, pubmed # model-organism gene -> OBSERVED knockout/mutant phenotypes (distinct from the upheno ontology-translation path). Reach from the model-organism gene directly: mgi/rgd/wormbase/xenbase >> alliance_phenotype >> mp gencc: mondo, hpo, hgnc, ensembl clingen_gene_validity: hgnc, entrez, ensembl, mondo # ClinGen gene-disease validity tier (Definitive..Refuted) + MOI clingen_dosage: entrez, hgnc, ensembl, mondo, mim, pubmed # ClinGen haploinsufficiency/triplosensitivity per gene clingen_variant: clinvar, hgnc, entrez, ensembl, mondo, pubmed # ClinGen VCEP ACMG variant pathogenicity (clinvar bridges to dbsnp) panelapp: panelapp_gene # Genomics England clinical gene panels (per-panel master); panel >> panelapp_gene >> hgnc for the panel's genes panelapp_gene: panelapp, hgnc, ensembl, mim, mondo # one per (panel,gene), green/amber confidence + mode-of-inheritance; a gene's panels via >>hgnc (panelapp_gene) ; the panel's disease via mondo/mim clinical_trials: mondo, chembl_molecule pharmgkb: hgnc, dbsnp, mesh, pharmgkb_gene, pharmgkb_variant, pharmgkb_clinical, pharmgkb_guideline, pharmgkb_pathway pharmgkb_variant: pharmgkb_clinical, hgnc, mesh, dbsnp pharmgkb_gene: hgnc, entrez, ensembl, pharmgkb pharmgkb_clinical: dbsnp, hgnc, mesh, pharmgkb_variant, pharmgkb # pharmgkb = reverse drug→clinical edge (drug >> pharmgkb >> pharmgkb_clinical) pharmgkb_guideline: hgnc, pharmgkb pharmgkb_pathway: hgnc, pharmgkb pharmgkb_var_annotation: hgnc, entrez, ensembl, dbsnp, pubmed # per-publication variant-annotation evidence (finding sentence, PMID, significance, study stats) beneath pharmgkb_clinical; reach via gene or rsID ctd: mesh, ctd_gene_interaction, ctd_disease_association, pubchem ctd_gene_interaction: ctd, entrez, taxonomy, pubmed ctd_disease_association: ctd, mesh, mim, pubmed intact: uniprot, chebi, rnacentral string: uniprot, string_interaction string_interaction: string, uniprot biogrid: entrez, uniprot, refseq, taxonomy bgee: ensembl, uberon, cl, taxonomy, bgee_evidence bgee_evidence: bgee, uberon, cl cellxgene: cl, uberon, mondo, efo, taxonomy cellxgene_celltype: cl, uberon, mondo scxa: cl, uberon, taxonomy, ensembl, scxa_gene_experiment scxa_expression: ensembl, scxa, scxa_gene_experiment scxa_gene_experiment: ensembl, scxa, scxa_expression, cl hpa: ensembl, uniprot, hgnc, entrez, go, uberon, hpa_expression, hpa_pathology, hpa_antibody # Human Protein Atlas gene card: subcellular location (→go), specificity calls, top tissues hpa_expression: hpa, uberon, cellosaurus # per (gene,tissue/cell-line) RNA nTPM + IHC staining; reach genes-in-a-tissue via uberon >> hpa_expression hpa_pathology: hpa # per (gene,cancer) prognostic survival association hpa_antibody: hpa, ensembl # HPA validation antibody (reliability, antigen) rnacentral: uniprot, ensembl, intact, hgnc, refseq, ena, go # go = Rfam-projected GO annotations; rfam_id/rfam_description are attrs on the entry ncrna_disease: hgnc, ensembl, mondo, efo, pubmed # curated ncRNA->disease (LncRNADisease + HMDD); reach from the ncRNA gene ncrna_interaction: hgnc, ensembl, uniprot, pubmed # experimentally-supported ncRNA->protein interactions (NPInter) ncrna_drug: hgnc, ensembl, chembl_molecule, pubchem, pubmed # ncRNA drug-resistance / drug-target (ncRNADrug) reactome: ensembl, uniprot, chebi, go, reactomeparent, reactomechild rhea: chebi, uniprot, go go: ensembl, uniprot, reactome, msigdb, swisslipids, bgee, interpro, goparent, gochild, hpa, rnacentral hpo: clinvar, gencc, mondo, msigdb, orphanet, mim, hmdb, hgnc, hpoparent, hpochild, upheno efo: gwas, mondo, cellxgene, efoparent, efochild, ncrna_disease upheno: hpo, mp, zp, xpo, wbphenotype, fypo, uphenoparent, uphenochild # cross-species phenotype hub. A GENE's model-organism phenotypes are reached THROUGH hpo (genes are NOT linked directly to mp/upheno): >>hgnc>>hpo>>upheno>>mp (mouse), >>hgnc>>hpo>>upheno>>zp (zebrafish), ...>>xpo/wbphenotype/fypo. So gene->human HP phenotypes -> their cross-species equivalents. mp: upheno, mpparent, mpchild, alliance_phenotype # Mammalian Phenotype Ontology (mouse/rat). Reach from a gene via >>hgnc>>hpo>>upheno>>mp (NOT >>hgnc>>mp); observed model phenotypes via alliance_phenotype. zp: upheno, zpparent, zpchild # Zebrafish Phenotype Ontology. Reach from a gene via >>hgnc>>hpo>>upheno>>zp. xpo: upheno, xpoparent, xpochild, alliance_phenotype # Xenopus Phenotype Ontology wbphenotype: upheno, wbphenotypeparent, wbphenotypechild, alliance_phenotype # C. elegans Phenotype Ontology fypo: upheno, fypoparent, fypochild # Fission Yeast Phenotype Ontology uberon: bgee, cellxgene, cellxgene_celltype, swisslipids, uberonparent, uberonchild, hpa, hpa_expression cl: bgee, cellxgene, cellxgene_celltype, scxa, scxa_gene_experiment, clparent, clchild taxonomy: ensembl, uniprot, bgee, biogrid, ctd_gene_interaction, taxparent, taxchild mesh: pharmgkb, ctd, ctd_disease_association, pubchem, mondo, chembl_molecule, meshparent, meshchild eco: ecoparent, ecochild antibody: ensembl, uniprot, mondo, pdb msigdb: hgnc, entrez, go, hpo orphanet: hpo, uniprot, mondo, hgnc, clinvar, mim, mesh mim: clinvar, hpo, mondo, uniprot, ctd_disease_association, panelapp_gene hmdb: pubchem, hpo, chebi, uniprot collectri: hgnc # transcription factor → target gene interactions esm2_similarity: uniprot # protein structural similarity diamond_similarity: uniprot # protein sequence similarity cellphonedb: uniprot, ensembl, hgnc, pubmed # ligand-receptor pairs for cell-cell communication spliceai: hgnc pdb: uniprot, go, interpro, pfam, taxonomy, pubmed fantom5_promoter: ensembl, hgnc, entrez, uniprot, uberon, cl fantom5_enhancer: ensembl, uberon, cl fantom5_gene: ensembl, hgnc, entrez jaspar: uniprot, pubmed, taxonomy encode_ccre: taxonomy bao: chembl_activity, chembl_assay, baoparent, baochild brenda: uniprot, pubmed, brenda_kinetics, brenda_inhibitor brenda_kinetics: brenda brenda_inhibitor: brenda gtopdb: uniprot, hgnc, gtopdb_ligand, gtopdb_interaction # drug targets (GPCRs, ion channels, enzymes) gtopdb_ligand: pubchem, chebi, chembl_molecule, gtopdb_interaction # ligands/drugs with binding data gtopdb_interaction: gtopdb, gtopdb_ligand, pubmed # target-ligand binding with affinity values civic: entrez, ensembl, civic_variant, civic_evidence, civic_assertion # clinical interpretation of cancer variants civic_variant: civic, clinvar, civic_evidence, civic_assertion, transcript civic_evidence: civic_variant, civic, mondo, chembl_molecule, pubmed, clinical_trials civic_assertion: civic_variant, civic, mondo, chembl_molecule intogen: hgnc, entrez, ensembl, mondo, pubmed # cancer driver genes cellosaurus: taxonomy, uniprot, hgnc, mondo, orphanet, clinvar, dbsnp, uberon, cl, chebi, doi, patent, pubmed, depmap_dependency, hpa_expression # cell lines (CVCL) generif: entrez, pubmed # NCBI cited per-gene functional claims (RAG grounding) depmap: entrez, hgnc, ensembl # CRISPR gene essentiality aggregate (cancer dependency / target tractability) depmap_dependency: entrez, cellosaurus # per cell-line gene dependency (effect < -0.5) FILTER SYNTAX: >>dataset[field operator value] OPERATORS: == equals >>dataset[field=="value"] != not equals >>dataset[field!="value"] > greater than >>dataset[field>value] < less than >>dataset[field<value] >= greater or equal >>dataset[field>=value] <= less or equal >>dataset[field<=value] contains string match >>dataset[field.contains("value")] LOGICAL OPERATORS: && AND >>dataset[field1>5 && field2<10] || OR >>dataset[field=="A" || field=="B"] ! NOT >>dataset[!field] or >>dataset[!(field=="value")] TYPE RULES: - FLOAT: use decimal point (70.0 not 70) - INT: no decimal (2 not 2.0) - STRING: quote values ("Pathogenic", "PHASE3") - BOOL: true/false (no quotes) EXAMPLES: >>chembl_molecule[highestDevelopmentPhase==4] # approved drugs >>chembl_molecule[highestDevelopmentPhase>=3] # Phase 3+ >>clinical_trials[phase=="PHASE3"] >>go[type=="biological_process"] >>clinvar[germline_classification=="Pathogenic"] >>reactome[name.contains("signaling")] >>gtopdb[type=="gpcr"] # GPCR targets >>gtopdb[type=="ion_channel"] # ion channel targets >>gtopdb_ligand[approved==true] # approved drugs only >>gtopdb_interaction[endogenous==true] # endogenous ligand interactions

  Connector

• get_summary

  Pubmed

  Resolve PubMed IDs (from search_pubmed) to citation metadata: title, authors, journal, publication date, DOI. Batch up to ~200 IDs per call as a comma-separated string — much cheaper than calling per-ID. Use when you have PMIDs and need the citation; for the abstract text use get_abstract instead.

  Connector

• openalex_resolve_name

  openalex-mcp-server

  Resolve a name or an identifier to an OpenAlex ID. ALWAYS use this before filtering by entity — names are ambiguous, IDs are not. A name returns up to 10 autocomplete matches with disambiguation hints. An identifier — OpenAlex ID, DOI, ORCID, ROR, PMID, PMCID, or ISSN, bare or in URL form — resolves directly to the one record it addresses, and needs no entity_type.

  Connector

• orcid_resolve_researcher

  orcid-mcp-server

  Disambiguate an author name to a verified ORCID iD. Returns ranked candidates (5 by default, up to 20 via the rows parameter) with transparent disambiguation signals: name match type (exact/partial/other-name/none), institution overlap flag, and whether a DOI or PMID anchor was used in the query. A DOI or PMID anchor is near-deterministic — it filters to researchers who have linked that specific work to their ORCID record. Use this tool (not orcid_search_researchers) when the input is an ambiguous name that needs ranked disambiguation. No synthetic scores are used — raw signals only.

  Connector

• paper_details

  LiveDataLink

  Get full catalog metadata for a single scholarly work by OpenAlex id (e.g. 'W2741809807') or DOI (e.g. '10.1038/nature12373'). Returns title, authors, venue, year, citation count, open-access status, and a free full-text URL when available. For a bare arXiv id, use paper_get_text with paper_key 'arxiv:<id>' to read indexed text, or paper_search by title for OpenAlex metadata.

  Connector

• formatCitation

  Scholar Sidekick

  Format scholarly identifiers into a finished citation in a specific style. Use when the user wants a paste-ready citation string for a manuscript, slide, message, footnote, or in-line reference. Style defaults to vancouver if unspecified; ask the user before defaulting if any ambiguity exists (e.g. 'Harvard' and 'Chicago' have multiple variants — confirm which one). Supports five hand-tuned builtins (vancouver, ama, apa, ieee, cse) plus any of 10,000+ CSL style IDs (chicago-author-date, harvard-cite-them-right, modern-language-association, nature, bmj, the-lancet, etc.). Alias and dependent-style resolution apply, so 'harvard' resolves to 'harvard-cite-them-right' and the canonical ID is reported back as styleUsed. Output defaults to text; pass output=html for marked-up HTML or output=json for structured CSL items. Accepts the same identifier formats as resolveIdentifier (DOI/PMID/PMCID/ISBN/arXiv/ISSN/ADS/WHO IRIS, prefixes tolerated), single or comma/newline-separated batch — one round trip per call. Returns: one of { text, html, items } depending on the output parameter, followed by a metadata block ({formatter: 'builtin' | 'csl', styleUsed, requestId, warnings?}) appended as a second text content item — surface this to the user when they care about reproducibility. Use resolveIdentifier instead when the user wants raw metadata to inspect or transform; use exportCitation when they want a downloadable bibliography file. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier.

  Connector

• checkRetraction

  Scholar Sidekick

  Check whether a single scholarly work has been retracted, corrected, or had an expression of concern raised. Use when the user asks 'has this paper been retracted?' or wants to verify a paper's standing before citing it (clinical, regulatory, evidence-synthesis contexts). For multi-paper bibliography audits (clinical guidelines, systematic reviews), loop one call per identifier — the tool intentionally rejects batch input to keep retraction-status results unambiguous per work. Sourced from Crossref `updated-by` (which mirrors Retraction Watch). Resolves DOI/PMID/PMCID/arXiv/ADS inputs to a DOI before lookup; ISBN inputs always return doi=null and reason='no_doi' since books are not in the retraction graph. Single identifier per call — does NOT accept comma/newline batches; loop one call per identifier for multiple papers. Returns: { doi, resolvedFrom?, reason?, result } where result has isRetracted, hasCorrections, hasConcern (booleans), notices (array of {type, label, doi, date, source} where type is a raw Crossref update type such as 'retraction', 'correction', 'erratum' or 'expression_of_concern'), and title; result is null when no DOI could be resolved and reason explains why ('no_doi'). No sibling tool overlaps this — resolveIdentifier returns metadata but not retraction status. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier; Crossref is queried server-side with its own caching.

  Connector

• checkOpenAccess

  Scholar Sidekick

  Check whether a single scholarly work is openly accessible and where to find the best legal version. Use when the user asks 'is this open access?', 'where can I read this for free?', or wants the OA license/version before reusing or redistributing. Sourced from Unpaywall. Resolves DOI/PMID/PMCID/arXiv/ISBN/ADS inputs to a DOI before lookup; inputs that don't map to a DOI return doi=null and reason='no_doi'. Single identifier per call — does NOT accept comma/newline batches; loop one call per identifier for multiple papers. Returns: { doi, resolvedFrom?, reason?, result } where result has isOa (boolean), oaStatus ('gold' | 'green' | 'hybrid' | 'bronze' | 'closed'), title, bestLocation ({url, hostType: 'publisher' | 'repository', license, version: 'submittedVersion' | 'acceptedVersion' | 'publishedVersion'} or null), and locations (array of the same shape); result is null when no DOI could be resolved and reason explains why ('no_doi'). No sibling tool overlaps this — resolveIdentifier returns metadata but not OA status. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier; Unpaywall is queried server-side with its own caching.

  Connector

• verifyCitation

  Scholar Sidekick

  Verify a claimed citation against the resolved record at its identifier. Detects the dominant AI-driven fabrication pattern documented by Topaz et al. (Lancet 2026): a real, resolvable identifier (DOI / PMID / PMCID / arXiv / etc.) paired with a title that does NOT correspond to the paper at that identifier. Use when the user pastes a citation and asks 'is this real?' or 'check this DOI' — most fabricated citations resolve cleanly under doi.org but their cited title and the resolved title disagree. Single citation per call. Required: `title` plus exactly one identifier (doi, pmid, pmcid, isbn, arxiv, issn, ads, or whoIrisUrl). Optional refinements: author (first-author family name), year, container (journal). Set `screenWithLlm: true` to invoke the Stage 3 LLM screen on low-confidence mismatches (catches informal-abbreviation false positives); LLM access is gated to authenticated first-party keys and paid RapidAPI tiers — anonymous callers get 400 LLM_SCREEN_FORBIDDEN. Returns: { verdict: 'matched' | 'mismatch' | 'not_found' | 'ambiguous', confidence: 'high' | 'medium' | 'low', matched: <resolved record or null>, mismatches: [{field, claimed, resolved, similarity}], candidates: [{item, registries, score}] (when title-search ran), _provenance: {stages_run, resolved_via, registries_searched, llm_screen} }. Verdict semantics: 'matched' = claim agrees with resolved record; 'mismatch' = identifier resolves but title does not match (Topaz fabrication pattern); 'ambiguous' = identifier resolves to one paper but the claimed title matches a DIFFERENT paper found via title-search (CITADEL 'citation error' subtype — wrong identifier for a real paper); 'not_found' = neither the identifier nor the title resolves anywhere. No sibling tool overlaps: resolveIdentifier returns metadata for a known-good identifier; verifyCitation is the only tool that cross-checks claimed title vs resolved metadata. Read-only and idempotent — safe to retry. Works anonymously for the non-LLM path; the Stage 3 LLM screen requires authentication — set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) or use a paid RapidAPI tier. SCHOLAR_API_KEY also raises your rate limit.

  Connector

• openfinance_force_sync

  Banco do Brasil MCP

  Forces the bank to re-sync one or more connections NOW and WAITS for it to finish (PATCH /items/:id, then polls until the item stops updating, up to ~60s). Use this when a balance or transaction list looks stale: a connection can read UPDATED yet be hours old, and this pulls fresh data WITHOUT disconnecting/reconnecting. Pass `items` as an array of selectors (item_id, connector_id, connector_name, or the user-set custom_label nickname); OMIT `items` to sync ALL linked banks. Returns `{ results, errors }`; each result has the final `status`, `executionStatus`, `lastUpdatedAt` (advances when data is refreshed), and `synced` (true = fresh data is ready). `needs_action` (e.g. MFA_REINTERACTION / LOGIN_ERROR / WAITING_USER_INPUT) means the user must re-authenticate — those results include a `reconnect_url` that opens the widget in UPDATE mode for that exact connection (user enters credentials / MFA token, data refreshes in place, no slot consumed, no disconnect needed). `timed_out: true` means the sync is still running — re-check with openfinance_get_item_status. Set `wait: false` for fire-and-forget (returns immediately while UPDATING).

  Connector

• openfinance_list_transactions

  Banco do Nordeste do Brasil MCP

  Returns transactions for a bank account (BANK or CREDIT type). For CREDIT (credit card) accounts, this is the ONLY way to get itemized transactions (purchases, subscriptions, etc.). Each credit card transaction MAY carry `creditCardMetadata.billId` pointing at a bill from openfinance_list_credit_card_bills, but this is a per-connector HINT, not authoritative: some connectors (e.g. Nubank) populate it sparsely (many transactions and installments arrive with no billId) or inconsistently (the same payment tagged to more than one bill). Do NOT reconstruct a bill's total by summing transactions by billId — the bill's own `totalAmount` from openfinance_list_credit_card_bills is the source of truth. CREDIT PENDING vs POSTED varies by connector: where the bank exposes future-dated `status:'PENDING'` installments, those represent the OPEN bill plus future bills (future months); where it does NOT, only the last closed bill's POSTED items appear until ~closing. Same query, different coverage per bank (upstream). To get a standardized open-bill total / total debt regardless, use openfinance_list_credit_card_bills (`open_bill` / `total_pending_debt`). Supports from/to date filters (ISO YYYY-MM-DD) and an optional keyword filter via `search_queries` (case- and accent-insensitive substring match against description and merchant name, OR semantics across multiple terms). When `search_queries` is set the tool aggregates up to 5000 transactions within from/to before filtering — narrow from/to if `truncated:true` is returned. PAGINATION: OMIT both `page` and `page_size` (the default) to get ALL transactions in the from/to range in one call — the tool auto-paginates the upstream and returns them under a single logical page (`page:1`, `totalPages:1`), up to a 5000 ceiling (`truncated:true` + warning if exceeded, then narrow from/to). Passing `page` and/or `page_size` switches to MANUAL pagination: you get one page (`page_size` items, default 50, max 500; `page` defaults to 1) with the REAL `total`/`totalPages`, so `page_size:5` alone returns the first 5 with `totalPages` telling you how many pages remain. On upstream errors, returns { total:0, results:[], warning, error } instead of throwing. `detail` controls how much per-row data you get (default `'compact'` = slim, cheap). Use `detail:'rich'` to enrich each row (when the bank connector provides it) with `merchantInfo` (estabelecimento: businessName/razão social, cnpj, cnae, category — useful for auto-classifying spending) and extra `creditCardMetadata` fields: `billId` (a per-connector HINT toward the transaction's bill — sparse/inconsistent on some connectors like Nubank, so do NOT sum by it to get a bill total; use the bill's `totalAmount` instead), `purchaseDate`, `payeeMCC`, `feeType`/`feeTypeAdditionalInfo`, `otherCreditsType`/`otherCreditsAdditionalInfo`. Use `detail:'raw'` to get the FULL untouched Pluggy transaction object (everything Pluggy returns, un-normalized — heaviest, for when you need a field we don't project). 'rich'/'raw' add tokens per row and coverage varies by bank/Open Finance, so keep the default for normal listings. For the card's statement closing/due dates use openfinance_list_accounts (`creditData.balanceCloseDate` / `balanceDueDate`). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH account/bank these transactions belong to. When more than one bank is connected, ALWAYS cross-check the echo against the account you intended to query and name the bank when presenting results — never attribute one bank's transactions to another. If total is 0 for a CREDIT account, check the connection health via openfinance_get_item_status — `statusDetail.creditCards.isUpdated: false` means the credit card sync failed and a force sync (openfinance_force_sync) or reconnection may be needed. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a connected bank: transactions may come back incomplete or wrong until the provider recovers, and reconnecting does not fix it. Bulk support: accepts account_ids for batched execution.

  Connector

• openfinance_list_transactions_by_item

  Banco do Nordeste do Brasil MCP

  Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call. Resolves the connection's accounts internally and fans out their transactions, so you do NOT need to call openfinance_list_accounts first nor carry account_id uuids between calls. Pass `item` (connector_id, connector_name or item_id) to target one bank, or OMIT it to analyze ALL linked banks at once. `from`/`to` are ISO dates (YYYY-MM-DD). Default `granularity:'monthly'` returns a COMPACT summary (no raw rows): total entradas, saídas, saldo_liquido, monthly evolution (`por_mes`), and `top_despesas`/`top_recebimentos` (largest N each), plus a per-account breakdown (`by_account`). Use this for 'análise anual/mensal', 'fluxo de caixa', 'entradas e saídas', 'maiores gastos/recebimentos'. Set `granularity:'raw'` to ALSO get every consolidated transaction (heavier — only when itemized rows are needed); combine with `detail:'rich'` to enrich those rows with merchantInfo (cnpj/cnae/businessName/category) + extra creditCardMetadata (billId, purchaseDate, fees), or `detail:'raw'` for the full untouched Pluggy object per row, when the connector provides them. `type` filters BANK or CREDIT accounts. On a connection with many transactions the scan caps at 5000/account and flags `truncated:true`. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a connected bank: the totals/rows may be incomplete or wrong until the provider recovers, and reconnecting does not fix it. Bulk support: accepts item_ids for batched execution.

  Connector

• openfinance_list_credit_card_bills

  Banco do Nordeste do Brasil MCP

  Returns CLOSED credit card bills for a CREDIT-type account: dueDate, totalAmount, minimumPaymentAmount, allowsInstallments, plus `payments[]` (id, paymentDate, amount, valueType, paymentMode), `payments_count`, `payments_total`, finance charges aggregates, and a derived `payment_status` per bill. IMPORTANT — Brazilian Open Finance semantics: Pluggy does NOT return a `paid`/`status` field. The payment goes into the `payments[]` of the bill whose CYCLE contains the paymentDate (closing ≈ dueDate − 7d): pre-payment before close stays on the bill being paid; payment between close and due, or after due, lands on the NEXT bill. So `payments[]` on a bill commonly carries the previous bill's payment, NOT the current one's — do NOT assume this bill was paid just because `payments[]` is non-empty. Use the derived `payment_status` (`PAID` | `OPEN` | `PAST_DUE_UNCONFIRMED` | `PAST_DUE_UNPAID`): a bill is `PAID` when its OWN `payments[]` (early pre-payment) or ANY newer bill in the payload contains a payment with amount ≈ this bill's `totalAmount` (±R$0.50). The MOST RECENT bill that's past-due, with no own pre-payment match, cannot be confirmed via cross-bill (the next cycle hasn't closed yet) — it returns `PAST_DUE_UNCONFIRMED`. NEVER call such a bill 'vencida' categorically; flag that the payment may have been made between close and due and not yet reflected upstream. The full `payment_status_legend` is returned alongside the results. OPEN BILL & TOTAL DEBT (standardized, derived — OPT-IN): pass `include_open_bill:true` to ALSO get `open_bill` (the current not-yet-closed bill, próxima a vencer) and `total_pending_debt` (saldo devedor total = all pending installments), BOTH derived from PENDING transactions so they mean the same thing across connectors — use these instead of the CREDIT account's `balance`, whose meaning VARIES by connector (some report the open-bill partial, others the full installment debt). `open_bill` = { available, method (`cycle_dates` = real close/due dates | `calendar_month_fallback` = estimated, `confidence:'low'`), close_date, due_date, total_amount (net charges − credits), transaction_count }; plus a `future_bills[]` breakdown per month — LOW-confidence forward projections of PENDING installments (`confidence:'low'`, `basis`), NOT authoritative bills (for closed months trust the `results` `totalAmount`). CONNECTOR ASYMMETRY: where the bank does NOT expose the open bill before closing (only closed bills, no reliable cycle dates), `open_bill.available` is `false` with a `reason` (`connector_exposes_no_pending` or `open_bill_not_published`) — that bill isn't retrievable by any endpoint until it closes (upstream limit of the institution's Open Finance feed, not our filter); check the bank app for the current open bill. When per-transaction billId grouping does not reconcile with the bills' totals, a `bill_grouping_reliability` warning is attached (trust `totalAmount`, do not sum by billId). Default `false` (the projection runs an extra accounts+transactions scan, so it's opt-in). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH card/bank these bills belong to. When more than one bank is connected, ALWAYS cross-check the echo against the card you intended to query and name the bank when presenting results — never attribute one bank's bills to another. This tool's `results` are bill-level summaries — NOT individual transactions, and each bill's `totalAmount` (from the bank) is the AUTHORITATIVE amount. To see itemized purchases/charges, use openfinance_list_transactions with the CREDIT account_id — but note `creditCardMetadata.billId` is a per-connector hint that can be sparse/inconsistent (e.g. Nubank), so do NOT reconstruct a bill total by summing transactions by billId. Returns a warning instead of failing if the CREDIT_CARDS product is not enabled. Bulk support: accepts account_ids for batched execution.

  Connector