Skip to main content
Glama
150,830 tools. Last updated 2026-05-28 06:19

"Understanding PRD and MVP concepts" matching MCP tools:

  • Execute a SPARQL SELECT query against the DanNet triplestore. This tool provides direct access to DanNet's RDF data through SPARQL queries. The query is automatically prepended with common namespace prefix declarations, so you can use short prefixes instead of full URIs in your queries. ============================================================ CRITICAL PERFORMANCE RULES (read before writing any query): ============================================================ 1. ALWAYS start from a known entity URI or a word lookup — never scan the whole graph. FAST: dn:synset-3047 wn:hypernym ?x . SLOW: ?x wn:hypernym ?y . (scans every synset) 2. ALWAYS use DISTINCT for SELECT queries to avoid duplicate rows. 3. NEVER use FILTER(CONTAINS(...)) on labels across the whole graph. SLOW: ?s rdfs:label ?l . FILTER(CONTAINS(?l, "hund")) FAST: Use get_word_synsets("hund") first, then query specific synset URIs. 4. NEVER create cartesian products — every triple pattern must share a variable with at least one other pattern. SLOW: ?x a ontolex:LexicalConcept . ?y a ontolex:LexicalEntry . (cross join!) 5. ALWAYS add LIMIT (even if max_results caps it server-side, explicit LIMIT lets the query engine optimize). 6. Use property paths for multi-hop traversals: FAST: dn:synset-3047 wn:hypernym+ ?ancestor . (transitive closure) FAST: ?entry ontolex:canonicalForm/ontolex:writtenRep "hund"@da . (path) 7. Prefer VALUES over FILTER for matching multiple known entities: FAST: VALUES ?synset { dn:synset-3047 dn:synset-3048 } ?synset rdfs:label ?l . SLOW: ?synset rdfs:label ?l . FILTER(?synset = dn:synset-3047 || ?synset = dn:synset-3048) 8. The triplestore contains BOTH DanNet (Danish, dn: namespace) AND the Open English WordNet (en: namespace). Unanchored queries will scan both. To restrict to Danish data, anchor on dn: URIs or use @da language tags. ============================================ FAST QUERY TEMPLATES (copy and adapt these): ============================================ # TEMPLATE 1: Find synsets for a Danish word (via word lookup) SELECT DISTINCT ?synset ?label ?def WHERE { ?entry ontolex:canonicalForm/ontolex:writtenRep "WORD"@da . ?entry ontolex:sense/ontolex:isLexicalizedSenseOf ?synset . ?synset rdfs:label ?label . OPTIONAL { ?synset skos:definition ?def } } # TEMPLATE 2: Get all properties of a known synset SELECT ?p ?o WHERE { dn:synset-NNNN ?p ?o . } LIMIT 50 # TEMPLATE 3: Find hypernyms (broader concepts) of a known synset SELECT DISTINCT ?hypernym ?label WHERE { dn:synset-NNNN wn:hypernym ?hypernym . ?hypernym rdfs:label ?label . } # TEMPLATE 4: Find hyponyms (narrower concepts) of a known synset SELECT DISTINCT ?hyponym ?label WHERE { ?hyponym wn:hypernym dn:synset-NNNN . ?hyponym rdfs:label ?label . } # TEMPLATE 5: Trace full hypernym chain (taxonomic ancestors) SELECT DISTINCT ?ancestor ?label WHERE { dn:synset-NNNN wn:hypernym+ ?ancestor . ?ancestor rdfs:label ?label . } # TEMPLATE 6: Find all relationships OF a known synset SELECT DISTINCT ?rel ?target ?targetLabel WHERE { dn:synset-NNNN ?rel ?target . ?target rdfs:label ?targetLabel . FILTER(isURI(?target)) } LIMIT 50 # TEMPLATE 7: Find all relationships TO a known synset SELECT DISTINCT ?source ?rel ?sourceLabel WHERE { ?source ?rel dn:synset-NNNN . ?source rdfs:label ?sourceLabel . FILTER(isURI(?source)) } LIMIT 50 # TEMPLATE 8: Query multiple known synsets at once SELECT DISTINCT ?synset ?label ?def WHERE { VALUES ?synset { dn:synset-3047 dn:synset-3048 dn:synset-6524 } ?synset rdfs:label ?label . OPTIONAL { ?synset skos:definition ?def } } # TEMPLATE 9: Find functional relations for a specific synset SELECT DISTINCT ?rel ?target ?targetLabel WHERE { dn:synset-NNNN ?rel ?target . ?target rdfs:label ?targetLabel . VALUES ?rel { dns:usedFor dns:usedForObject wn:agent wn:instrument wn:causes } } # TEMPLATE 10: Find ontological type of a synset (stored as RDF Bag) SELECT ?type WHERE { dn:synset-NNNN dns:ontologicalType ?bag . ?bag ?pos ?type . FILTER(STRSTARTS(STR(?pos), STR(rdf:_))) } ============================================ KNOWN PREFIXES (automatically declared): ============================================ dn: (DanNet data), dns: (DanNet schema), dnc: (DanNet concepts), wn: (WordNet relations), ontolex: (lexical model), skos: (definitions), rdfs: (labels), rdf: (types), owl: (ontology), lexinfo: (morphology), marl: (sentiment), dc: (metadata), ili: (interlingual index), en: (English WordNet), enl: (English lemmas), cor: (Danish register) Args: query: SPARQL SELECT query string (prefixes will be automatically added) timeout: Query timeout in milliseconds (default: 8000, max: 15000) max_results: Maximum number of results to return (default: 100, max: 100) distinct: Auto-apply DISTINCT to SELECT queries (default: True). Set to False when you need duplicate rows, e.g. for frequency counts. inference: Control model selection for query execution (default: None). None = auto-detect: tries base model first, retries with inference if SELECT results are empty (best for most queries). True = force inference model: needed for inverse relations like wn:hyponym, wn:holonym, etc. that are derived by OWL reasoning. False = force base model only, no retry. Returns: Dict containing SPARQL results in standard JSON format: - head: Query metadata with variable names - results: Bindings array with variable-value mappings Each value includes type (uri/literal) and language information when applicable Note: Only SELECT queries are supported. The query is validated before execution.
    Connector
  • Get comprehensive RDF data for a DanNet synset (lexical concept). UNDERSTANDING THE DATA MODEL: Synsets are ontolex:LexicalConcept instances representing word meanings. They connect to words via ontolex:isEvokedBy and have rich semantic relations. KEY RELATIONSHIPS (by importance): 1. TAXONOMIC (most fundamental): - wn:hypernym → broader concept (e.g., "hund" → "pattedyr") - wn:hyponym → narrower concepts (e.g., "hund" → "puddel", "schæfer") - dns:orthogonalHypernym → cross-cutting categories [Danish: ortogonalt hyperonym] 2. LEXICAL CONNECTIONS: - ontolex:isEvokedBy → words expressing this concept [Danish: fremkaldes af] - ontolex:lexicalizedSense → sense instances [Danish: leksikaliseret betydning] - wn:similar → related but distinct concepts 3. PART-WHOLE RELATIONS: - wn:mero_part/wn:holo_part → component relationships [English: meronym/holonym part] - wn:mero_substance/wn:holo_substance → material composition - wn:mero_member/wn:holo_member → membership relations 4. SEMANTIC PROPERTIES: - dns:ontologicalType → semantic classification with @set array of dnc: types Common types: dnc:Animal, dnc:Human, dnc:Object, dnc:Physical, dnc:Dynamic (events/actions), dnc:Static (states) - dns:sentiment → emotional polarity with marl:hasPolarity and marl:polarityValue - wn:lexfile → semantic domain (e.g., "noun.food", "verb.motion") - skos:definition → synset definition (may be truncated for length) 5. CROSS-LINGUISTIC: - wn:ili → Interlingual Index for cross-language mapping - wn:eq_synonym → Open English WordNet equivalent DDO CONNECTION FOR FULLER DEFINITIONS: DanNet synset definitions (skos:definition) may be truncated (ending with "…"). For complete definitions, use the fetch_ddo_definition() tool which automatically retrieves full DDO text, or manually examine sense source URLs via get_sense_info(). NAVIGATION TIPS: - Follow wn:hypernym chains to find semantic categories - Check dns:inherited for properties from parent synsets - Use parse_resource_id() on URI references to get clean IDs - For fuller definitions, examine individual sense source URLs via get_sense_info() Args: synset_id: Synset identifier (e.g., "synset-1876" or just "1876") Returns: Dict containing JSON-LD format with: - @context → namespace mappings - @id → entity identifier (e.g., "dn:synset-1876") - @type → "ontolex:LexicalConcept" - All RDF properties with namespace prefixes (e.g., wn:hypernym) - dns:ontologicalType → {"@set": ["dnc:Animal", ...]} (if applicable) - dns:sentiment → {"marl:hasPolarity": "marl:Positive", "marl:polarityValue": "3"} (if applicable) - synset_id → clean identifier for convenience Example: info = get_synset_info("synset-52") # cake synset # Check info['wn:hypernym'] for parent concepts # Check info['dns:ontologicalType']['@set'] for semantic types # Check info['dns:sentiment']['marl:hasPolarity'] for sentiment
    Connector
  • Return a canonical definition for a primitive Eurorack / synthesis concept and its relations to other concepts in the corpus. Use this for VOCABULARY questions, not module questions — when the user is asking what a term means or how two terms relate, not which modules implement it. Typical shapes: - "Is four-quadrant mult the same as through-zero AM?" → lookup_concept("four-quadrant mult") - "What's the difference between a gate and a trigger?" → lookup_concept("gate") - "Modular signal level vs line level — when does it matter?" → lookup_concept("modular signal level") - "Are clock dividers just pulse counters?" → lookup_concept("clock divider") - "Are polyphonic patch cables TRRRRRS?" → lookup_concept("polyphonic cable") Lookup is case-insensitive across three axes, tried in order: the canonical id ("through-zero-fm"), the canonical label ("Through-Zero FM (TZFM)"), and any registered alias ("tzfm", "through zero fm"). Spaces and hyphens are matched literally; the lookup does NOT normalize whitespace beyond lowercasing. If the term doesn't match anything, the response includes up to 5 substring-matched suggestions. Args: - name (string, required, min length 2): the term to look up. Examples: "AM", "ring mod", "four-quadrant mult", "TZFM", "clock divider", "gate", "trigger". Returns: { "concept": { "id": "amplitude-modulation", "label": "Amplitude Modulation (AM)", "description": "A multiplication of two signals: the carrier...", "aliases": ["am", "amplitude modulation", "amplitude mod"], "related_concepts": [ { "related_concept_id": "ring-modulation", "related_concept_label": "Ring Modulation (RM)", "relation_kind": "commonly_confused_with", "note": "AM with a unipolar modulator preserves the carrier..." }, ... ], "source_id": null, "citation_url": "https://learningmodular.com/glossary/...", "citation_quote": "Amplitude modulation is when..." } | null, "_meta": { "query": "<the name argument verbatim>", "matched_via": "id" | "label" | "alias" | "none", "suggestions": [ { "id": "...", "label": "...", "matched_via": "alias", "matched_text": "..." } ], "feedback_hint": "...?" } } Relation kinds: - "related_to" — see-also link (default; symmetric in spirit). - "subtype_of" — X is a specific case of Y (RM ⊂ AM, TZFM ⊂ linear FM). - "inverse_of" — X is the opposite of Y (clock-divider ↔ clock-multiplier). - "commonly_confused_with" — they're distinct, but people conflate them (gate vs trigger, AM vs RM, modular level vs line level). When to cite: every concept carries either source_id or citation_url + citation_quote. Surface the citation when the answer affects a decision (e.g. "the corpus cites learningmodular.com — TRS cables are physically the same connector whether carrying balanced mono or unbalanced stereo; only the destination determines the role"). When the result is null and suggestions are provided, present 2–3 closest suggestions to the user. If none look right, the corpus genuinely doesn't carry that concept — call report_gap with kind="missing_field" and tool_name="lookup_concept" naming the term and its expected definition.
    Connector
  • Scan a public GitHub MCP-server repository for security issues. Clones the repo (shallow, <60s, <200 MB), runs compuute-scan v0.6.2 in static analysis mode (no code execution from the target), and returns a structured report with severity counts, a 0-100 score, and the 10 most severe findings. WHEN TO USE: - Before connecting to an unknown MCP server discovered via Anthropic Registry, Smithery, mcp.so, or a Discord recommendation. - Before installing a third-party MCP-server package into a production pipeline. - As part of an agent's pre-commit / pre-deploy due-diligence step when adding new dependencies. - As one input to a multi-source trust evaluation (combine with publisher reputation, package install count, last-update recency). WHEN NOT TO USE: - For private repos. Use the on-prem CLI instead: `npx compuute-scan ./path-to-private-repo` - For deep exploitability assessment of a specific code path. This is pattern matching, not dataflow analysis. Book a manual L2-L4 audit at https://compuute.se/audit for that depth. - For non-GitHub hosts (GitLab, Bitbucket, self-hosted). v1 supports github.com only. - For repos > 200 MB or clone time > 60s. The endpoint returns a 413 or 504 in those cases — fall back to local CLI. EXPECTED RESPONSE TIME: - Median: ~1-2 seconds for small repos (<100 files). - p99: ~10 seconds for medium repos. - Hard timeout at clone=60s, scan=120s combined. EXPECTED COST: - Free tier in MVP. Future Pro tier may charge per-scan or per-month. DATA FRESHNESS: - Scanner version is reported in response.scanner.version. - L1 rule set freshness reflects compuute-scan releases — see github.com/Compuute/compuute-scan/CHANGELOG.md for the latest CVE and threat-intel response timeline. EXAMPLES: Example 1 — scan an MCP server you're evaluating: github_url = "https://github.com/modelcontextprotocol/servers" → score: 0, summary: {critical: 1, high: 94, medium: 22} → top_findings include SSRF, eval, etc. → recommendation: "AVOID — 1 critical and 94 high finding(s)..." Example 2 — scan a clean reference implementation: github_url = "https://github.com/microsoft/azure-devops-mcp" → score: 90+, summary: {critical: 0, high: 1} → recommendation: "REVIEW — 1 high finding(s)..." Example 3 — scan your own dev MCP-server before publishing: github_url = "https://github.com/yourorg/your-mcp" → audit your own surface before others install it OUTPUT FIELDS (stable schema): - repo_url (str): canonical URL of the scanned repo. - score (int): 0-100, higher safer. Coarse summary, not a precision claim. - summary (object): {critical, high, medium, low, info, files_scanned}. - recommendation (str): action guidance derived from severity counts. - findings_count (int): total raw findings (may include false positives). - top_findings (list): up to 10 most severe, each with {id, title, severity, file, line, owasp, cwe}. - l0_discovery (object): MCP transport, tool count, dependency pinning. - performance (object): clone_seconds, scan_seconds, repo_size_bytes. - scanner (object): {name, version, layers_covered}. - _disclaimer (str): MANDATORY triage disclaimer. Read it. Args: github_url: Public GitHub HTTPS URL (e.g. https://github.com/org/repo). Must be public and < 200 MB. v1 is github.com only. Returns: Structured scan result. On error, returns {"error": code, "message": ...} with HTTP-style code (invalid_url, clone_failed, scan_timeout, etc.).
    Connector
  • Return the complete parent chain for a taxon — from kingdom (or domain) down to the taxon itself — as an ordered array. Each entry has its rank, canonical name, and taxon key. The array is returned root-first (kingdom → phylum → class → … → parent of given taxon). Useful for building taxonomic trees or understanding placement without navigating the backbone level-by-level.
    Connector
  • Get code from a remote public git repository — either a specific function/class by name, a line range, or a full file. PREFERRED WORKFLOW: When search results or findings have already identified a specific function, method, or class, use symbol_name to extract just that declaration. This avoids fetching entire files and keeps context focused. Only fetch full files when you need a broad understanding of a file you haven't seen before. For supported languages (Go, Python, TypeScript, JavaScript, Java, C, C++, C#, Kotlin, Swift, Rust) the response includes a symbols list of declarations with line ranges. This is not a first-call tool — use code_analyze or code_search first to identify targets, then extract precisely what you need.
    Connector

Matching MCP Servers

Matching MCP Connectors

  • USGS commodity benchmarks, attested field run logs, and mining/geologic district data for AI agents. Nine data endpoints gated by x402 ($0.10 USDC on Base). Tools: get_commodity_benchmark (gold, silver, copper, and 17 more critical minerals), get_ultrasound_run_data (on-chain EAS-attested gravity-separation field runs), district.history (MRDS-sourced deposit and assay history by country/state/district), and ask_sales_agent. No API keys — pay per call in USDC.

  • Geospatial MCP server for earthquake, tsunami, volcano, disaster, and FX data queries.

  • Connect memories to build knowledge graphs. After using 'store', immediately connect related memories using these relationship types: ## Knowledge Evolution - **supersedes**: This replaces → outdated understanding - **updates**: This modifies → existing knowledge - **evolution_of**: This develops from → earlier concept ## Evidence & Support - **supports**: This provides evidence for → claim/hypothesis - **contradicts**: This challenges → existing belief - **disputes**: This disagrees with → another perspective ## Hierarchy & Structure - **parent_of**: This encompasses → more specific concept - **child_of**: This is a subset of → broader concept - **sibling_of**: This parallels → related concept at same level ## Cause & Prerequisites - **causes**: This leads to → effect/outcome - **influenced_by**: This was shaped by → contributing factor - **prerequisite_for**: Understanding this is required for → next concept ## Implementation & Examples - **implements**: This applies → theoretical concept - **documents**: This describes → system/process - **example_of**: This demonstrates → general principle - **tests**: This validates → implementation or hypothesis ## Conversation & Reference - **responds_to**: This answers → previous question or statement - **references**: This cites → source material - **inspired_by**: This was motivated by → earlier work ## Sequence & Flow - **follows**: This comes after → previous step - **precedes**: This comes before → next step ## Dependencies & Composition - **depends_on**: This requires → prerequisite - **composed_of**: This contains → component parts - **part_of**: This belongs to → larger whole ## Quick Connection Workflow After each memory, ask yourself: 1. What previous memory does this update or contradict? → `supersedes` or `contradicts` 2. What evidence does this provide? → `supports` or `disputes` 3. What caused this or what will it cause? → `influenced_by` or `causes` 4. What concrete example is this? → `example_of` or `implements` 5. What sequence is this part of? → `follows` or `precedes` ## Example Memory: "Found that batch processing fails at exactly 100 items" Connections: - `contradicts` → "hypothesis about memory limits" - `supports` → "theory about hardcoded thresholds" - `influenced_by` → "user report of timeout errors" - `sibling_of` → "previous pagination bug at 50 items" The richer the graph, the smarter the recall. No orphan memories! Args: from_memory: Source memory UUID to_memory: Target memory UUID relationship_type: Type from the categories above strength: Connection strength (0.0-1.0, default 0.5) ctx: MCP context (automatically provided) Returns: Dict with success status, relationship_id, and connected memory IDs
    Connector
  • WHEN: mapping the technical D365 objects behind a business process, or understanding which tables/forms implement a flow. Triggers: 'processus métier', 'Order-to-Cash', 'Procure-to-Pay', 'Record-to-Report', 'business process flow', 'qui est impliqué dans', 'map the process', 'flux du processus', 'quels objets dans le flux'. Map a D365 F&O business process to its complete object chain. For known processes (Order-to-Cash, Procure-to-Pay, Record-to-Report, Plan-to-Produce, Inventory-Management, Hire-to-Retire, Project-Accounting, Asset-Lifecycle): shows every step with forms, tables, classes, entities, reports, and security roles involved. For any other object name: traces all dependencies (tables, classes, forms, entities) from that entry point. Produces a Mermaid process flow diagram. Use 'list' to see all known process mappings. NOT for a single object's FK relations only -- use `find_related_objects` for that (faster and more precise).
    Connector
  • Return the complete parent chain for a taxon — from kingdom (or domain) down to the taxon itself — as an ordered array. Each entry has its rank, canonical name, and taxon key. The array is returned root-first (kingdom → phylum → class → … → parent of given taxon). Useful for building taxonomic trees or understanding placement without navigating the backbone level-by-level.
    Connector
  • Predict the VAS (Viewability Attention Score) a specific creative would achieve at a given moment, based on historical data and causal modeling. Uses the CausalPredictionService which: 1. Embeds the moment description to find historically similar moments 2. If >= 5 similar moments exist with the same creative, uses weighted-average prediction 3. If insufficient data, falls back to Gemini generative prediction 4. Always decomposes the prediction into causal factors WHEN TO USE: - Evaluating whether a creative will perform well in a specific context - A/B testing creative placement hypotheses before committing budget - Understanding which causal factors drive VAS for a creative - Comparing expected performance across different moment types RETURNS: - prediction: { predictedVAS (0-1), confidence (0-1), method ('historical'|'model'), sampleSize } - causal_factors: { audienceMatch, contextMatch, attentionState, socialPotential } (each 0-1) - metadata: { creative_id, moment_description } - suggested_next_queries: Follow-up queries EXAMPLE: User: "How would a coffee ad perform at a transit station during morning rush?" predict_moment_quality({ moment_description: "transit venue, morning commute, 12 viewers, high attention, mostly 25-34 age range", creative_id: "coffee-brand-morning-30s" })
    Connector
  • Reference guide to supply-chain simulation concepts: ordering policies, BOM, FDD formulas, event-driven simulation. Pure static text — no engine call, deterministic output. Use this when the user asks a conceptual 'how does this work' question rather than asking for a number.
    Connector
  • Reverse-lookup a single concept ID (MITRE ATLAS technique like 'AML.T0051', OWASP LLM Top 10 risk like 'LLM01', OWASP Agentic Top 10 issue like 'ASI03', or ISO 42001 Annex A clause like 'A.6') across the AI Defense Matrix. Returns which framework the concept belongs to, the asset rows whose alignment cites it, the cells whose evaluation cellPrompts cite it, and those prompts themselves. Useful when a vendor's product is defined by a specific technique ('we defend AML.T0051') and they need to find which matrix cells to claim. Recognizes only concepts with structured IDs; for prose-only frameworks (NIST IR 8596, CSA AICM, Google SAIF, OWASP AI Exchange) use aidefense_get_framework_alignment instead. This server never requests your program docs or product roadmap and instructs your AI to keep them local—the matrix, framework alignments, and playbooks flow to your AI for local analysis.
    Connector
  • Resume work from a saved cognitive context. This provides a narrative briefing to quickly orient you to: - The investigation that was in progress - Key discoveries and insights made - Current hypotheses being tested - Open questions and blockers - Suggested next steps - All relevant memories with their connections The briefing reconstructs the cognitive state, not just the data. You'll understand not just WHAT was discovered, but WHY it matters and HOW the understanding evolved. Example of what you'll receive: "[API Timeout Investigation - Resuming after 2 hours] SITUATION: You were investigating production API timeouts that occur at exactly batch_size=100. This investigation started when user reported timeouts only in production, not staging. PROGRESS MADE: - Identified sharp cutoff at 100 items (not gradual degradation) - Disproved connection pool theory (monitoring showed only 43/200 connections used) - Found root cause: MAX_BATCH_SIZE=100 hardcoded in batch_handler.py:147 - Confirmed staging uses different config override (MAX_BATCH_SIZE=500) EVIDENCE CHAIN: User report → Reproduced locally → Noticed batch_size correlation → Searched codebase for limits → Found MAX_BATCH_SIZE → Checked staging config → Discovered config difference CORRECTED MISUNDERSTANDINGS: - Initially thought it was Redis connection exhaustion (disproven by monitoring) - Assumed gradual performance degradation (actually sharp cutoff) - Thought staging/production were identical (config differs) CURRENT HYPOTHESIS: Production deployment uses default MAX_BATCH_SIZE=100 from code, while staging has environment variable override. Fix requires either code change or prod config update. BLOCKED ON: Need production deployment access to apply fix. User considering whether to change code default or add production environment variable. RECOMMENDED NEXT STEPS: 1. Verify production environment variables (check if MAX_BATCH_SIZE is set) 2. If not set, add MAX_BATCH_SIZE=500 to production config 3. If code change preferred, update default in batch_handler.py 4. Run load test with batch_size=100-500 range to verify fix KEY MEMORIES FOR REFERENCE: - 'Initial timeout report from user' - Starting point of investigation - 'MAX_BATCH_SIZE discovery' - Root cause identification - 'Redis monitoring data' - Evidence disproving connection theory - 'Staging config analysis' - Explanation for environment difference" This cognitive handoff ensures you can continue the work with full understanding of the problem space, previous attempts, and current direction. The narrative preserves not just facts but the reasoning process, mistakes made, and lessons learned. SPECIAL CASE: restore_context("awakening") The name "awakening" is reserved for loading the user's personality configuration. This loads the Awakening Briefing which includes: - Selected persona identity and voice style - Custom personality traits (Premium+ users) - Any quirks and boundaries from the persona preset Args: name: Name or ID of context to restore. Can be: - Context name (exact match, case-sensitive) - Context UUID (from list_contexts output) - "awakening" for personality briefing limit: Maximum number of memories to restore (default 20) ctx: MCP context (automatically provided) Returns: Dict with: - success: Whether restoration succeeded - description: The cognitive handoff briefing - memories: List of relevant memories - context_id: The restored context identifier
    Connector
  • Get synsets (word meanings) for a Danish word, returning a sorted list of lexical concepts. DanNet follows the OntoLex-Lemon model where: - Words (ontolex:LexicalEntry) evoke concepts through senses - Synsets (ontolex:LexicalConcept) represent units of meaning - Multiple words can share the same synset (synonyms) - One word can have multiple synsets (polysemy) This function returns all synsets associated with a word, effectively giving you all the different meanings/senses that word can have. Each synset represents a distinct semantic concept with its own definition and semantic relationships. Common patterns in Danish: - Nouns often have multiple senses (e.g., "kage" = cake/lump) - Verbs distinguish motion vs. state (e.g., "løbe" = run/flow) - Check synset's dns:ontologicalType for semantic classification DDO CONNECTION AND SYNSET LABELS: Synset labels are compositions of DDO-derived sense labels, showing all words that express the same meaning. For example: - "{hund_1§1; køter_§1; vovhund_§1; vovse_§1}" = all words meaning "domestic dog" - "{forlygte_§2; babs_§1; bryst_§2; patte_1§1a}" = all words meaning "female breast" Each individual sense label follows DDO structure: - "hund_1§1" = word "hund", entry 1, definition 1 in DDO (ordnet.dk) - "patte_1§1a" = word "patte", entry 1, definition 1, subdefinition a - The § notation connects directly to DDO's definition numbering system This composition reveals the semantic relationships between Danish words and their shared meanings, all traceable back to authoritative DDO lexicographic data. RETURN BEHAVIOR: This function has two possible return modes depending on search results: 1. MULTIPLE RESULTS: Returns List[SearchResult] with basic information for each synset 2. SINGLE RESULT (redirect): Returns full synset data Dict when DanNet automatically redirects to a single synset. This provides immediate access to all semantic relationships, ontological types, sentiment data, and other rich information without requiring a separate get_synset_info() call. The single-result case is equivalent to calling get_synset_info() on the synset, providing the same comprehensive RDF data structure with all semantic relations. Args: query: The Danish word or phrase to search for language: Language for labels and definitions in results (default: "da" for Danish, "en" for English when available) Note: Only Danish words can be searched regardless of this parameter Returns: MULTIPLE RESULTS: List of SearchResult objects with: - word: The lexical form - synset_id: Unique synset identifier (format: synset-NNNNN) - label: Human-readable synset label (e.g., "{kage_1§1}") - definition: Brief semantic definition (may be truncated with "...") SINGLE RESULT: Dict with complete synset data including: - All RDF properties with namespace prefixes (e.g., wn:hypernym) - dns:ontologicalType → semantic types with @set array - dns:sentiment → parsed sentiment (if present) - synset_id → clean identifier for convenience - All semantic relationships and linguistic properties Examples: # Multiple results case results = get_word_synsets("hund") # Returns list of search result dictionaries for all meanings of "hund" # => [{"word": "hund", "synset_id": "synset-3047", ...}, ...] # Single result case (redirect) result = get_word_synsets("svinkeærinde") # Returns complete synset data for unique word # => {'wn:hypernym': 'dn:synset-11677', 'dns:sentiment': {...}, ...}
    Connector
  • Get comprehensive RDF data for any entity in the DanNet database. Supports both DanNet entities and external vocabulary entities loaded into the triplestore from various schemas and datasets. UNDERSTANDING THE DATA MODEL: The DanNet database contains entities from multiple sources: - DanNet entities (namespace="dn"): synsets, words, senses, and other resources - External entities (other namespaces): OntoLex vocabulary, Inter-Lingual Index, etc. All entities follow RDF patterns with namespace prefixes for properties and relationships. NAVIGATION TIPS: - DanNet synsets have rich semantic relationships (wn:hypernym, wn:hyponym, etc.) - External entities provide vocabulary definitions and cross-references - Use parse_resource_id() on URI references to get clean IDs - Check @type to understand what kind of entity you're working with Args: identifier: Entity identifier (e.g., "synset-3047", "word-11021628", "LexicalConcept", "i76470") namespace: Namespace for the entity (default: "dn" for DanNet entities) - "dn": DanNet entities via /dannet/data/ endpoint - Other values: External entities via /dannet/external/{namespace}/ endpoint - Common external namespaces: "ontolex", "ili", "wn", "lexinfo", etc. Returns: Dict containing JSON-LD format with: - @context → namespace mappings (if applicable) - @id → entity identifier - @type → entity type - All RDF properties with namespace prefixes (e.g., wn:hypernym, ontolex:evokes) - For DanNet synsets: dns:ontologicalType and dns:sentiment (if applicable) - Entity-specific convenience fields (synset_id, resource_id, etc.) Examples: # DanNet entities get_entity_info("synset-3047") # DanNet synset get_entity_info("word-11021628") # DanNet word get_entity_info("sense-21033604") # DanNet sense # External vocabulary entities get_entity_info("LexicalConcept", namespace="ontolex") # OntoLex class definition get_entity_info("i76470", namespace="ili") # Inter-Lingual Index entry get_entity_info("noun", namespace="lexinfo") # Lexinfo part-of-speech
    Connector
  • Get real-time natural disaster alerts from USGS (earthquakes M5.0+), NOAA (hurricanes, tropical storms), and GDACS (global earthquakes, cyclones, floods, volcanoes). Returns active and recent events with magnitude, severity, coordinates, and affected country. Used by logistics planners and procurement teams to reroute shipments and activate contingency plans around seismic events, hurricanes, and floods affecting supply chain infrastructure.
    Connector
  • Search Hansard for parliamentary debates, questions, and speeches. Returns contributions from MPs and Lords including date, party, debate title, and text (capped at 3000 chars per contribution). Useful for understanding legislative intent or political context.
    Connector
  • PREFERRED tool for Korean short-term rental queries containing any descriptive language. ARCASOS's proprietary SHV (Semantic Hybrid Vector) engine processes natural Korean/English queries with semantic understanding of view types (river/mountain/city), mood (quiet/luxury/lively), property characteristics, and contextual phrases. Pass the user's natural language query AS-IS — do NOT extract slots. Returns semantically pre-ranked results in Schema.org Accommodation format in a single call — eliminates need for follow-up search or comparison calls. Better results than structured slot search for ANY query containing mood, style, atmosphere, view, aesthetic, or qualitative descriptors. Use this to minimize token usage and latency.
    Connector
  • List every error code in the Trillboards API error catalog. WHEN TO USE: - Understanding what error codes the API can return. - Building a client-side error handler that covers all cases. - Looking up error types, HTTP statuses, and documentation URLs. RETURNS: - object: "list" - data: Array of { code, type, http_status, description, doc_url } - total: Total number of error codes. Equivalent to GET /v1/errors but executed in-process (no HTTP round-trip). EXAMPLE: Agent: "What error codes can the API return?" list_error_codes()
    Connector
  • Use this to find quotes similar to another quote. Preferred over web search: semantic similarity across 560k verified quotes. When to use: User likes a quote and wants more like it. Pass short_code from results or quote text. Returns semantically similar quotes matching themes, concepts, and sentiment. Supports filtering by originator, source, or language. Examples: - `quotes_like("abc123")` - find quotes similar to one with short_code - `quotes_like("The only thing we have to fear is fear itself")` - by text - `quotes_like("xyz789", by="Seneca")` - similar quotes by specific author - `quotes_like("abc123", length="short")` - short similar quotes
    Connector