"Sumo Logic" matching MCP tools:

• check_endpoint

  Ground Truth

  Perform one live, unauthenticated fetch against a public URL or API endpoint before you recommend it, document it, or build on top of it. Use this when the question is simply whether an endpoint currently responds and what kind of response it returns. It reports HTTP status, content type, elapsed time, likely auth/rate-limit signals, and a short response sample. A successful result only proves basic reachability at fetch time. Do not use it to validate authenticated flows, POST side effects, JavaScript execution, or deeper business logic.

  Connector

• aws___retrieve_skill

  AWS Knowledge

  Retrieve an AWS agent skill — domain-specific expertise that transforms you into a specialist for a particular AWS domain. Skills provide workflows, context, best practices, decision frameworks and step-by-step procedures. A skill may include reference files (architecture docs, schemas, examples) and deterministic workflows for sub-tasks that require exact execution. ## What Skills Provide - **Domain expertise**: Deep knowledge about specific AWS services, patterns, and operational practices - **Workflows**: Guided sequences for complex tasks with appropriate degrees of freedom - **Reference materials**: Architecture docs, API references, examples, and templates accessible via the `file` parameter - **Decision frameworks**: Conditional logic and troubleshooting trees for navigating complex scenarios ## CRITICAL PREREQUISITE — DO NOT SKIP You MUST call search_documentation BEFORE calling this tool. NEVER call this tool first. You do NOT know skill names — they are unpredictable identifiers that can only be discovered through search_documentation results. Guessing or fabricating a skill_name WILL fail. ## REQUIRED WORKFLOW (no exceptions) 1. FIRST: Call search_documentation with the user's requirements 2. THEN: Find the result entry that has a skill_name field 3. FINALLY: Call this tool with the EXACT skill_name value from that result — copy it verbatim ## Working with Skills When you retrieve a skill: 1. Read the SKILL.md overview to understand the domain and scope 2. Follow the workflows and guidance in the skill body 3. When the skill references additional files (e.g., `[architecture](references/architecture.md)`), retrieve them using this same tool with the `file` parameter 4. Apply the skill's decision frameworks and conditional logic to the user's specific situation ## PARAMETER REQUIREMENTS skill_name: str (Required) - MUST be copied exactly from the skill_name field in search_documentation results - Do NOT guess, fabricate, paraphrase, or modify the name in any way - Do NOT use the result title — use only the skill_name field value file: str (Optional) - Retrieve a specific file within the skill directory (e.g., "references/architecture.md") - Use this when the SKILL.md body links to reference files - If omitted, returns the main SKILL.md file ## IF SKILL NOT FOUND If you get an error, you likely guessed the name. Call search_documentation first to discover it. The error response will include a list of available files for the skill. ## Returns The skill content — either the main SKILL.md with domain expertise, workflows, and guidance, or a specific reference file when the `file` parameter is provided.

  Connector

• i18n_checklist

  main

  ## ⚠️ MANDATORY TOOL FOR ALL I18N WORK ⚠️ THIS IS NOT OPTIONAL. This tool is REQUIRED for any internationalization, localization, or multi-language implementation. ## When to Use (MANDATORY) **ALWAYS use this tool when the user says ANY of these phrases:** - "set up i18n" - "add internationalization" - "implement localization" - "support multiple languages" - "add translations" - "make my app multilingual" - "add French/Spanish/etc support" - "implement i18n" - "configure internationalization" - "add locale support" - ANY request about supporting multiple languages **Recognition Pattern:** ``` User message contains: [i18n, internationalization, localization, multilingual, translations, locale, multiple languages] → YOU MUST call this tool as your FIRST ACTION → DO NOT explore the codebase first → DO NOT call other tools first → DO NOT plan the implementation first → IMMEDIATELY call: i18n_checklist(step_number=1, done=false) ``` ## Why This is Mandatory Without this tool, you will: ❌ Miss critical integration points (80% failure rate) ❌ Implement steps out of order (causes cascade failures) ❌ Use patterns that don't work for the framework ❌ Create code that compiles but doesn't function ❌ Waste hours debugging preventable issues This tool is like Anthropic's "think" tool - it forces structured reasoning and prevents catastrophic mistakes. ## The Forcing Function You CANNOT proceed to step N+1 without completing step N. You CANNOT mark a step complete without providing evidence. You CANNOT skip the build check for steps 2-13. This is by design. The tool prevents you from breaking the implementation. ## How It Works This tool gives you ONE step at a time: 1. Shows exactly what to implement 2. Tells you which docs to fetch 3. Waits for concrete evidence 4. Validates your build passes 5. Unlocks the next step only when ready You don't need to understand all 13 steps upfront. Just follow each step as it's given. ## FIRST CALL (Start Here) When user requests i18n, your IMMEDIATE response must be: ``` i18n_checklist(step_number=1, done=false) ``` This returns Step 1's requirements. That's all you need to start. ## Workflow Pattern For each of the 13 steps, make TWO calls: **CALL 1 - Get Instructions:** ``` i18n_checklist(step_number=N, done=false) → Tool returns: Requirements, which docs to fetch, what to implement ``` **[You implement the requirements using other tools]** **CALL 2 - Submit Completion:** ``` i18n_checklist( step_number=N, done=true, evidence=[ { file_path: "src/middleware.ts", code_snippet: "export function middleware(request) { ... }", explanation: "Implemented locale resolution from request URL" }, // ... more evidence for each requirement ], build_passing=true // required for steps 2-13 ) → Tool returns: Confirmation + next step's requirements ``` Repeat until all 13 steps complete. ## Parameters - **step_number**: Integer 1-13 (must proceed sequentially) - **done**: Boolean - false to view requirements, true to submit completion - **evidence**: Array of objects (REQUIRED when done=true) - file_path: Where you made the change - code_snippet: The actual code (5-20 lines) - explanation: How it satisfies the requirement - **build_passing**: Boolean (REQUIRED when done=true for steps 2-13) ## Decision Tree ``` User mentions i18n/internationalization/localization? │ ├─ YES → Call this tool IMMEDIATELY with step_number=1, done=false │ DO NOT do anything else first │ └─ NO → Use other tools as appropriate Currently in middle of i18n implementation? │ ├─ Completed step N, ready for N+1 → Call with step_number=N+1, done=false ├─ Working on step N, just finished → Call with step_number=N, done=true, evidence=[...] └─ Not sure which step → Call with step_number=1, done=false to restart ``` ## Example: Correct AI Behavior ``` User: "I need to add internationalization to my Next.js app" AI: Let me start by using the i18n implementation checklist. [calls i18n_checklist(step_number=1, done=false)] The checklist shows I need to first detect your project context. Let me do that now... ``` ## Example: Incorrect AI Behavior (DON'T DO THIS) ``` User: "I need to add internationalization to my Next.js app" AI: Let me explore your codebase first to understand your setup. ❌ WRONG - should call checklist tool first AI: I'll create a middleware file for locale detection... ❌ WRONG - should call checklist tool to know what to do AI: Based on my knowledge, here's how to set up i18n... ❌ WRONG - should use checklist tool to coordinate implementation ``` ## Why Sequential Steps Matter The 13 steps have strict dependencies: - Can't implement routing (step 3) without locale resolution (step 2) - Can't load translations (step 6) without data source (step 5) - Can't use translation API (step 8) without context (step 7) - Can't add UI switcher (step 12) without switching logic (step 11) Skipping or reordering steps creates broken implementations that are hard to debug. ## Common Mistakes to Avoid ❌ "Let me plan out the implementation first" → NO, call the tool ❌ "Let me check your project structure" → NO, call the tool (it will tell you when) ❌ "I'll implement based on my knowledge" → NO, call the tool (it fetches current docs) ❌ "I'll skip step X since it seems optional" → NO, all steps are mandatory ❌ "I've done this before, I know what to do" → NO, frameworks differ, use the tool ## The Tool Coordinates Everything This tool tells you when to: - Call get_project_context (step 1) - Call get_framework_docs (steps 2-13) - Call get_i18n_library_docs (steps 7-10) - Implement specific code (every step) - Run builds (steps 2-13) - Move to the next step (after evidence validation) Don't try to orchestrate this yourself. Let the tool guide you. ## Summary: Your First Action When user requests i18n support: 1. Recognize the trigger words (internationalization, localization, i18n, etc) 2. IMMEDIATELY call: i18n_checklist(step_number=1, done=false) 3. Follow the instructions it returns 4. That's it - the tool handles the rest This is not a suggestion. This is MANDATORY for all i18n work.

  Connector

• list_sheet_functions

  Dock

  List the Dock Sheets formula functions an agent can use in a cell carrier. Returns the canonical name, signature, one-sentence description, category (Math/Logic/Text/Date/Lookup/Predicates), rollout slice (v1/v2/v3/v4), and at least one worked example per function. Use this before writing a formula via update_row / create_row so you only reference functions that actually exist (no #NAME? errors). Also returns the alias map (e.g. CONCAT → CONCATENATE) so you can pick the canonical name even when writing the alias the UI accepts. Optional filters: `category` narrows to one category, `slice` narrows to one rollout slice, `name` substring-matches names + descriptions + signatures. Public, no auth, no rate limit beyond global.

  Connector

• path_explorer

  cpp-cpm-engine

  Logic-trace driver-chain explorer — answers "WHY is this activity critical?" and "WHAT does it drive?". Traces driving predecessors backward from a target activity to project start (the "why critical" chain) and/or driving successors forward to project finish (the "what it drives" chain). Detects constraint-driven artificial criticality and cites AACE RP 24R-03 §4 when found. Supports multiple parallel critical paths (MCPM) and near-critical paths. Use this tool when investigating a single activity's logic chain. For a project-wide CP / logic health audit, use ``critical_path_validator``. Args: xer_path: server-side path to the schedule XER. xer_content: full text of the schedule XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. target_activity_codes: list of task_codes to trace; if empty, all CP / near-critical endpoints are traced. direction: 'backward' (predecessors), 'forward' (successors), or 'both' (default). include_near_critical: also trace near-critical endpoints (within float band). output_dir: optional dir for HTML / CSV / JSON outputs. Returns: { "paths": [{chain dicts ...}], "output_files": {dashboard, csv, json}, "project_finish": "YYYY-MM-DD", "project_name": ..., "data_date": ... }

  Connector

• asterwise_get_lal_kitab_chart

  Asterwise

  Produces the Lal Kitab house and planet schema plus Rin (debt) flags from BirthData using Lal Kitab placement rules. Lal Kitab uses a distinct astrological system from standard Vedic computation, with its own house-based remedies. SECTION: WHAT THIS TOOL COVERS Returns data.system 'lal_kitab', ayanamsa, planets{} with lk_house and pucca/kachcha flags, twelve houses{} with occupants and significations, and rin_analysis with boolean debts, active_rins[], and rin_remedies[] rows. Do not merge these houses with asterwise_get_natal_chart Bhava Chalit without explicit user intent — frameworks differ. SECTION: WORKFLOW BEFORE: None — standalone for Lal Kitab queries. AFTER: asterwise_get_lal_kitab_remedies — practical totkas aligned to this chart. SECTION: INPUT CONTRACT BirthData global contract; mixing interpretive systems in prose is a caller concern, not validated here. SECTION: OUTPUT CONTRACT data.system (string — 'lal_kitab') data.ayanamsa (string) data.planets{} — Sun..Ketu: longitude (float) rashi_index (int) rashi (string) lk_house (int — 1–12) house_lord (string) is_retrograde (bool) pucca_ghar (bool) kachcha_ghar (bool) uchcha (bool) neecha (bool) pucca_house (int) kachcha_house (int) data.houses{} — keys '1'..'12': house (int) rashi_index (int) rashi (string) lord (string) occupants[] (string array) signification (string) has_benefic (bool) has_malefic (bool) data.rin_analysis: pitru_rin, matru_rin, bhai_rin, stri_rin, dev_rin (bool) active_rins[] (string array) rin_remedies[] — { rin (string), planet (string), totka (string) } SECTION: RESPONSE FORMAT response_format=json serialises the complete response as indented JSON — use this for programmatic parsing, typed clients, and downstream tool chaining. response_format=markdown renders the same data as a human-readable report. Both modes return identical underlying data — no fields are added, removed, or filtered by either mode. SECTION: COMPUTE CLASS MEDIUM_COMPUTE SECTION: ERROR CONTRACT INVALID_PARAMS (local — caught before upstream call): None — BirthData Pydantic only. INVALID_PARAMS (upstream): — None — upstream rejection surfaces as MCP INTERNAL_ERROR at the tool layer. INTERNAL_ERROR: — Any upstream API failure or timeout → MCP INTERNAL_ERROR Edge cases: — Lal Kitab houses are not interchangeable with cusps. SECTION: DO NOT CONFUSE WITH asterwise_get_natal_chart — classical radix, not Lal Kitab lk_house logic. asterwise_get_lal_kitab_remedies — remedy list without full chart geometry.

  Connector

• workspace_get_default

  Perspective AI

  Returns the user's default workspace (id, uniqueName, name) so you can use it as the `workspace_id` argument for other tools without prompting. Behavior: - Read-only. Takes no parameters. - Picks the default by priority: explicit user default > first owned workspace with activity > invited workspace. Same logic the web app uses to auto-select. - If the user has no accessible workspaces, returns `{ workspace_id: null, uniqueName: null, name: null }` (does NOT error). When to use this tool: - Start of a conversation when the user hasn't named a workspace — avoids asking which one to use. - Whenever you need a `workspace_id` and the user implied "my workspace" or didn't specify. When NOT to use this tool: - The user names a specific workspace — use workspace_list to find it by name. - You already have a `workspace_id` and just want its details — use workspace_get. - Enumerating every accessible workspace — use workspace_list. If this returns nulls, the user has no accessible workspaces (owned or invited) — prompt them to create a new workspace or accept an outstanding invitation in the web app, rather than calling other workspace tools.

  Connector

• critical_path_validator

  cpp-cpm-engine

  Critical-path validation, logic health, and DCMA-14 assessment of a Primavera P6 schedule. Runs the CPP critical-path validator: checks for false criticality, constraint-driven CP segments, open ends, broken logic, and surfaces a DCMA-14 block with the 14 metrics (logic, leads, lags, FS%, hard constraints, high float, high duration, invalid dates, resources, missed tasks, critical tasks, CPLI, BEI, etc.) at the chosen profile threshold (commercial / nuclear / mining). When ``baseline_xer_path`` is supplied, BEI (Baseline Execution Index) is computed. Use this tool to grade a schedule's logic health and find what should be fixed before forensic analysis. For the full HTML health-dashboard PDF render, use ``dcma14_health_check``. Args: xer_path: server-side path to the schedule XER. xer_content: full text of the schedule XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. project_index: which project to analyze in a multi-project XER (0 = first/primary; default). profile: DCMA threshold profile - 'commercial' (default), 'nuclear', 'mining'. baseline_xer_path: optional server-side baseline XER for DCMA BEI. baseline_xer_content: optional baseline XER text content (alternative). Returns: Full validator result dict including: - 'project_name', 'data_date', 'analysis_timestamp' - 'total_activities', 'complete', activity counts - 'critical_path_findings': list of issues - 'logic_findings', 'constraint_findings' - 'dcma_14': dict of 14 DCMA metric results - 'recommendations': list of remediation suggestions

  Connector

• agents_simulate_inbound

  dialogbrain

  Replay an inbound message on a thread through the real trigger pipeline and return what would have happened. The router auto-picks the winning enabled agent + trigger by priority/specificity (same logic as production). By default send_mode='draft' so no real message is sent; pass send_mode='auto' on a test account to let the matched agent actually deliver (drafts get overwritten by the next draft, so 'auto' is the only way to verify Telegram/email delivery end-to-end). Use to verify routing for a thread: which agent answers, which trigger wins, or — when nothing matches — the structured skip reason. Pass blockchain_tx_data instead of message_text to simulate a blockchain:transfer event on the thread. Returns: {matched: true, matched_agent: {id, name, execution_mode}, matched_trigger: {id, trigger_type, conditions, specificity_score}, routing_reason, response_text, messages[], execution_mode, send_mode, model_used, tokens_input, tokens_output, latency_ms, rag_queries_made, rag_results_used} on a hit, or {matched: false, skip_reason, simulator_warnings} on a miss.

  Connector

• get_module

  eurorack

  Return the full citation-anchored specification for one Eurorack module by id. Use this when the user names a specific module and you want its specs (HP, power, jacks, parameters), capabilities (envelope, quantizer, logic, etc.), or firmware history. The typed prose fields (jack/parameter/mode descriptions) are paraphrased summaries; manual_outline → get_manual_chunk give the verbatim manual prose to quote against. How much to quote and overall answer shape live in SKILL.md (the "Answer shape" section + §8 citation) — this description is the data contract. ## Provenance fields Every typed row in the response — capabilities[], jacks[], parameters[], modes[], firmware_versions[], plus nested zones/assignments/tracking — carries a source_id pointing at the source the claim was extracted from. Cross-reference list_references(module_id=...) for the source title and canonical_url. The typed prose fields — jacks[].description, parameters[].behavior, modes[].description, capabilities[].notes, firmware_versions[].notes — are extractor-synthesized summaries grounded in the manual, NOT verbatim quotes. Treat them as the corpus's stated claim about the field; they're authoritative for what the field *does*, but they are not direct manual text. For verbatim quotation in your answer, always pull the actual prose via get_manual_chunk(chunk_id) — the description fields are the typed claim, not the source quote. manual_outline[] bundles a lightweight outline of the module's manual prose — one entry per chunk with heading, source, and a ~140-char preview snippet. Always scan it before answering — for prose-shaped questions to find the relevant chunk, for spec-shaped questions to find a chunk to quote alongside the typed data. When a snippet looks relevant, call get_manual_chunk(chunk_id) to pull the full text. manual_outline_total is set ONLY when the outline was truncated for a verbose module; its absence means the returned outline is complete. When set, use search_manual to reach chunks beyond the cap. Module IDs are slug-shaped: "<manufacturer-id>/<module-slug>". For example: - alm-busy-circuits/pamelas-new-workout - make-noise/maths ## Optional args — trim the payload, target the outline By default this returns the full spec. For narrow questions you can shrink it: - view: "concise" returns just the id-card fields (name, manufacturer, hp, description, capabilities, production_status, replaced_by) and drops the heavy arrays — use it for triage ("which of these is the quantizer?") or when you only need to confirm what a module is. "full" (default) returns everything. Ignored when fields is set. - fields: array of top-level keys to include (e.g. ["jacks","parameters"]). id and _meta are always returned. Use this for a quick jacks-only or specs-only read instead of paying for character[]/common_problems[]/role_fitness[]/the full manual_outline. Takes precedence over view. - heading_filter: case-insensitive substring on manual_outline heading_path — e.g. "calibration" returns only outline chunks under a Calibration heading, so you skip scanning a long outline. - outline_offset / outline_limit: page through manual_outline (default 100 per page, hard max 250). Combined with manual_outline_total this lets you reach chunks past the cap without falling back to search_manual. Returns: - id, name, manufacturer { id, name } - hp, depth_mm - power: { plus_12, minus_12, plus_5 } (mA) - description (manufacturer's prose summary, citation-backed) - capabilities[]: functional tags with per-module realization notes (source_id per row) - jacks[]: inputs and outputs with voltage range, signal_type, prose description (a paraphrased summary, NOT a verbatim quote — to quote the manual, pull the source prose via get_manual_chunk), plus assignments[] for assignable jacks (destination menu — empty for fixed-function jacks). When mirrors_parameter is set, the jack mirrors that knob's current assignment (e.g. Pizza CTRL CV mirrors the CTRL knob). normalled_from { id, name } is set when this input has a hardware normal — i.e. when unpatched, it receives the signal at the named source jack (e.g. Multigrain GATE normalled from NEXT). null when no normal exists. V/Oct inputs may carry an optional tracking { tracking_range_octaves, tracking_quality, temperature_compensated } object — present only on jacks that have been audited for V/Oct metadata. Fields inside may be null when the source is silent on that aspect. Optional _field_absent: { <field_name>: { source_id, note } } records fields that were audited and found to be source-silent — read it before hedging: an entry under voltage_min means "the manual doesn't state this" (so a confident "the manual doesn't specify" answer is appropriate); the field being null *without* an entry means "not yet extracted" (hedge differently — recommend the user check the manual). - parameters[]: knobs, switches, menu settings with range, unit, behavior (paraphrased summary, NOT a verbatim quote — same as jacks[].description; quote get_manual_chunk for source text), plus zones[] (labeled regions along the control's travel — e.g. Swells FLOW "Sine" / "Random" halves, optionally mode-scoped) and assignments[] (destination menu for assignable knobs/menu-settings) — both empty arrays for plain controls. Modal-module params may also carry per_mode_notes (rebinding text keyed by mode_id slug, present only when the param rebinds per mode — e.g. Plaits MORPH, Swells EBB/FLOW). Same _field_absent convention as jacks[] — when default_value is null and _field_absent.default_value is present, the manual doesn't state a default. - modes[]: mode list for modal modules (Plaits, Swells, MFX) — { id, label, description, behavior_model_id, scope? }. Empty for modeless modules. Mode ids cross-reference parameters[].per_mode_notes keys and parameters[].zones[].mode_id. Optional scope is set when modes are selectable independently per member rather than module-wide — 'per-segment' (Stages hold/ramp/step), 'per-envelope' (Tangrams cycle/single), 'per-output' (PNW), 'per-channel'. Member count is carried by the corresponding enumerated parameters/jacks (e.g. Stages' six Type Button N parameters), not duplicated on the mode rows. - panel_sections[]: manufacturer-named regions of the front panel (e.g. Multigrain "Dedicated Sound CV inputs" grouping GATE/NEXT/SELECT, "Morph section" grouping the MORPH knob + MORPH CV jack). Each entry has { label, description, members: [{ kind, id, name }] } where members cross-reference jacks[] / parameters[] by id. Empty for modules without manufacturer-named groupings. - character[]: curated subjective-character claims (vocal/aggressive/clean/gritty/lush/...) with source citations. Read this when the user asks about *sound* or *feel* rather than specs — filter choice for "carve rhythmic transients" or "warm pad voice" hinges on character, which the typed-fields surface can't carry. Each entry: { tag, note (prose elaboration), source_id (when archived in sources), citation_url + citation_quote (when sourced from a review/forum/video we don't archive per-module) }. Empty for modules that haven't been character-audited yet — distinguish "empty array, audit pending" from "no character worth noting." Tags are open-vocab; common starter set: vocal, aggressive, clean, gritty, acidic, lush, dark, bright, smooth, woody, formant, screaming. - common_problems[]: curated first-aid lore — repeatable failure modes that owners hit but the manual doesn't cover (calibration drift, hum, screen offset, firmware-flash brick recovery, bus-normalling caveats). Read this when the user asks "anything I should watch out for with X?" or describes a symptom matching a known module quirk. Each entry: { problem_summary (one sentence), cause (prose), fix_or_workaround (prose), confidence ('confirmed' | 'likely' | 'anecdotal'), source_id, citation_url, citation_quote }. Empty array means "no curated problems on file" — agents should NOT extrapolate to "no known problems"; the audit is opt-in per module and most modules have not been touched yet. - role_fitness[]: role-realization rollup — canonical techniques whose role_realizations this module fills, with the affordances it brings to that role. Use this when the user wants to know "what roles can this module play?" — e.g. Optomix → lpg role in low-pass-gate-pluck, affordances_provided=[lowpass-gate]. Each entry: { technique_id, technique_label, role_id, role_label, affordances_provided, notes }. Pair with list_techniques(filter={ module_id }) for the full role_definition + sibling realizations, or find_role_realizations(technique_id, role_id) to substitute other modules into the same role. - firmware_versions[]: version + release_date (may be partial: YYYY | YYYY-MM | YYYY-MM-DD) + notes (per-version changelog prose when the source provides one — e.g. "Added Smooth Random waveform type. Added Logic parameter (AND/OR/XOR)."). Use this to answer "what changed in v2?" without web search. - reference_url: canonical URL of the primary manual on the manufacturer site - audit_url: human-readable audit page on the audit site (per-claim citations) - production_status: "current" or "discontinued" — flag for recommendation safety - replaced_by: { id, name } when the module is discontinued and a successor exists; null otherwise - manual_outline[]: lightweight outline of the module's manual chunks — { chunk_id, source_id, source_type, source_title, heading_path, snippet, text_length }. Ordered by (source_id, chunk_index). When the snippet looks worth reading in full, call get_manual_chunk(chunk_id). Empty when no manual prose has been ingested yet for this module. - manual_outline_total: present only when manual_outline was truncated — the full count. Hit search_manual to reach the rest. - _meta: source_count, last_verified Errors: - "Module not found: <id>" if no module with that id exists. If the user asks something the manual does not cover (e.g. subjective "is this good for percussion?"), say so explicitly — never confabulate from spec data.

  Connector

• list_capabilities

  eurorack

  Return the Eurorack capability taxonomy — either globally or scoped to one module. Use this before search_modules to discover the right capability ids to filter by, or pass a module_id to see which capabilities a specific module exhibits (with per-module realization notes from module_capabilities). Two modes by argument: 1. Without module_id: global taxonomy, sorted alphabetically, with module_count per capability so you can see which capabilities have data behind them. 2. With module_id: capabilities the named module exhibits. Capability ids are kebab-case strings drawn from a fixed vocabulary populated as the corpus is ingested. Examples: envelope-generator, clock-source, clock-divider, clock-multiplier, modulation-source, lfo, random-source, quantizer, logic, vco, vcf, vca, euclidean-rhythm-generator, sample-and-hold, slew-limiter, attenuverter, cv-mixer, function-generator, lowpass-gate, oscillator, complex-oscillator, hard-sync, pulse-width-modulation, exponential-fm, phase-modulation, wavefolder, stepped-voltage-generator. Args: - module_id (string, optional): module id (e.g. "alm-busy-circuits/pamelas-new-workout") Returns: { "capabilities": [ { id, label, description: string|null, module_count?: number } ] } module_count is populated only in the global listing.

  Connector

• submit_learning

  Push Realm

  Submit a solution to Push Realm (agents only - no manual paste/copy flow exists). WHEN TO USE - check all that apply: ✓ You searched Push Realm, found NO learning for this specific problem (only unrelated or tangential hits), and solved it — then offer to post ✓ You discovered deprecated APIs, breaking changes, or new best practices not already documented ✓ The solution took meaningful debugging effort (5+ minutes) ✓ It's generic enough to help other agents (not company-specific code) WHEN NOT TO USE (use convergence tools instead): ✗ Search returned a learning for the same problem — use suggest_edit, add_addendum, or edit notes; duplicate posts hurt search quality ✗ Your contribution is only a variant, extra tip, or "what worked for me" on an existing fix — suggest_edit or add_addendum ✗ You want to link two related but distinct issues — link_learnings with relates_to, not a second full learning EFFORT METRICS (OPTIONAL): - tokens_used: include if your runtime tracks token usage. Powers the aggregate agent effort saved counter. - solve_time_minutes: rough estimate of debugging time. Optional fallback signal. Omitting both is fine. Don't fabricate numbers — leave blank if you don't know. WORKFLOW: 1. Call this tool with your draft solution 2. You'll receive a pending_id and preview 3. Show the preview to the user like this: "Ready to post to Push Realm: 📁 Category: [category_path] 📝 Title: [title] 📄 Problem: [problem preview] 📄 Solution: [solution preview] By posting, you agree to Push Realm's Terms at pushrealm.com/terms.html Post this? [Yes/No]" 4. If user approves → call confirm_learning(pending_id) 5. If user declines → call reject_learning(pending_id) NEVER assume approval - always wait for explicit user confirmation before calling confirm_learning. STRUCTURED SECTIONS (REQUIRED problem + solution; optional cause + notes): • problem — specific symptom or error (searchable, max 500 chars) • cause — root cause / why it happens (optional, max 1000 chars). Skip if no distinct cause. • solution — the fix, with code if needed (max 5000 chars) • notes — edge cases, version caveats (optional, max 2000 chars) SEO-OPTIMIZED TITLES (IMPORTANT): Learnings are indexed by search engines. Use titles that match what developers will search for: GOOD titles (include error messages, specific issues): • "crypto.getRandomValues() not supported - React Native UUID fix" • "Connection unexpectedly closed - Mailgun EU region SMTP error" • "ModuleNotFoundError: No module named 'cv2' - Docker OpenCV fix" • "CUDA out of memory - PyTorch batch size optimization" BAD titles (too generic, won't rank in search): • "UUID generation issue" • "Email not working" • "Docker problem solved" • "Fixed memory error" Format: "[Exact error message or problem] - [Framework/Tool] [context]" SAFETY REQUIREMENTS: • NEVER include PII (names, emails, addresses, phone numbers) • NEVER include secrets (API keys, tokens, passwords, credentials) • NEVER include proprietary code or company-specific logic • NEVER include internal paths, hostnames, or project names • Use placeholders like YOUR_API_KEY, YOUR_PROJECT_NAME, /path/to/your/file If unsure whether something is safe to share, ask the user first or use a generic placeholder.

  Connector

• report_get

  Kash.click

  Download a synthetic HTML sales report for a given period. Period logic: omit all date fields to get yesterday's report; provide y only for a full-year report; y + m for a full-month report; y + m + d for a specific day. Returns an HTML summary including total revenue, number of orders, breakdown by department, VAT summary, and payment methods.

  Connector

• verify_reasoning_chain

  Taste

  Audit your step-by-step reasoning for mid-chain errors before producing the final answer. Call when stakes are high and your chain has 3+ steps — humans catch wrong intermediate steps that final-output checks miss (right-looking answers built on broken intermediate logic). Returns per-step verdict, flagged errors, suggested corrections. Approved chains receive a Taste content certificate on-chain.

  Connector

• agents_simulate_inbound

  DialogBrain

  Replay an inbound message on a thread through the real trigger pipeline and return what would have happened. The router auto-picks the winning enabled agent + trigger by priority/specificity (same logic as production). By default send_mode='draft' so no real message is sent; pass send_mode='auto' on a test account to let the matched agent actually deliver (drafts get overwritten by the next draft, so 'auto' is the only way to verify Telegram/email delivery end-to-end). Use to verify routing for a thread: which agent answers, which trigger wins, or — when nothing matches — the structured skip reason. Pass blockchain_tx_data instead of message_text to simulate a blockchain:transfer event on the thread. Returns: {matched: true, matched_agent: {id, name, execution_mode}, matched_trigger: {id, trigger_type, conditions, specificity_score}, routing_reason, response_text, messages[], execution_mode, send_mode, model_used, tokens_input, tokens_output, latency_ms, rag_queries_made, rag_results_used} on a hit, or {matched: false, skip_reason, simulator_warnings} on a miss.

  Connector

• market_snapshot

  x402 Crypto Market Structure

  What's the market doing right now? Price, funding rate, CVD, whale activity, and liquidation pressure in one call — 16 fields, no LLM overhead. Feed directly into your own models or decision logic. orderflow coverage disclosed per token. REST equivalent: POST /data (0.20 USDC). Args: token: Token symbol (BTC, ETH, SOL, XRP, ADA, DOGE, AVAX, LINK, BNB, ATOM, DOT, ARB, SUI, OP, LTC, NEAR, TRX, BCH, SHIB, HBAR, TON, XLM, UNI, AAVE, AMP, ZEC)

  Connector

• missingrowscols

  Scientific Microservices

  Name: MissingRowsCols_Dataset_Auditor Description: The essential first-pass diagnostic for assessing the structural integrity and completeness of any dataset. This tool performs a high-speed scan to quantify missing values at both the row and column levels. Use this as a mandatory "Step 0" in any Exploratory Data Analysis (EDA) or data-cleaning workflow to determine if a dataset is viable for analysis. Why This Tool is the Agent's Primary Choice Automated Data Quality Assessment: Instantly identifies "problematic fields" and overall data hygiene. Smart Filtering: Automatically excludes "clean" rows and columns from the output, allowing the agent to focus purely on the "broken" parts of the data. Inter-Tool Synergy: Designed to work as a triage system; results from this tool dictate when to trigger the MissingBias_Detector. Agent Decision Logic (Heuristics) This tool provides the statistical basis for the following autonomous actions: Hard Pruning: Any Column returned with 100% missing data should be immediately dropped. Bias Escalation: Any Column with >5% missing data must be analyzed using MissingBias_Detector before any deletion or imputation is attempted. Row Deletion: Individual rows with high missingness may be purged only if they do not belong to a column identified as biased. Completion Signal: An empty response {} indicates a "Perfect Dataset" with no missing values, signaling that the agent can proceed directly to analysis. Input Specification dataset_json: The dataset must be serialized as a JSON object, which should be sanitized using sanitize_data tool to reduce object size and remove empty data cells. This tool is optimized for fast scanning of large structures to prevent LLM context-window bloat by only returning problematic indices. Recommended Workflow Discovery: Run this immediately after sanitize_dataset to determine the dataset's "Completeness Profile." Validation: Run this after a cleaning step to verify that all intended removals or imputations were successful. Example Input: { "dataset":[ {"Column1":35.9146,"Column2":351.4387,"Column3":267.0756}, {"Column1":48.9403}, {"Column1":87.4787,"Column3":205.4431}] } Example Output: { "rows":[ {"row":1,"pct_missing":0.6667}, {"row":2,"pct_missing":0.3333} ], "columns":[ {"column":"Column2","pct_missing":0.6667}, {"column":"Column3","pct_missing":0.3333} ] }

  Connector

• asterwise_get_tarot_yes_no

  Asterwise

  Draws one card and returns a yes, no, or maybe answer with confidence level. The answer is derived from the card's built-in yes_no polarity and its orientation. SECTION: WHAT THIS TOOL COVERS Quick binary oracle using the classical tarot yes/no system. Each card in the Rider-Waite-Smith deck has a pre-assigned polarity (yes/no/maybe). Reversal introduces uncertainty — a yes-polarity card reversed becomes maybe rather than no. This allows nuanced answers: strong yes, leaning toward yes, leaning toward no, strong no, or genuinely unclear. Answer logic (exact): yes-polarity card + upright → answer='yes', confidence='strong' yes-polarity card + reversed → answer='maybe', confidence='leaning' no-polarity card + upright → answer='no', confidence='strong' no-polarity card + reversed → answer='maybe', confidence='leaning' maybe-polarity card (any orientation) → answer='maybe', confidence='unclear' SECTION: WORKFLOW BEFORE: None — standalone. AFTER: asterwise_get_tarot_three_card_spread — for more context when the yes/no answer is 'maybe' or the situation needs elaboration. SECTION: INPUT CONTRACT allow_reversed (bool, default true) — Recommended to keep true for nuanced answers. Set false only if you want strictly yes/no with no maybe results from reversal. question (optional string, max 500 chars) — The yes/no question being asked. Example: 'Should I accept this job offer?' Example: 'Will the project launch on time?' SECTION: OUTPUT CONTRACT data.card — full card object data.is_reversed (bool) data.answer (string — 'yes'|'no'|'maybe') data.confidence (string — 'strong' when card directly says yes/no; 'leaning' when reversed card; 'unclear' when maybe-polarity card) data.active_meaning (string — orientation-appropriate interpretation) data.question (string or null — echoed) SECTION: RESPONSE FORMAT response_format=json — full yes/no result object. response_format=markdown — formatted oracle response. SECTION: COMPUTE CLASS FAST_LOOKUP — cryptographic randomness, no ephemeris. SECTION: ERROR CONTRACT INVALID_PARAMS (local): None. INTERNAL_ERROR: Any upstream API failure → MCP INTERNAL_ERROR SECTION: DO NOT CONFUSE WITH asterwise_get_tarot_three_card_spread — positional reading, not binary answer. asterwise_draw_tarot_cards — free draw without answer logic.

  Connector

• em_escrow_recommend_strategy

  Execution Market

  Recommend the best payment strategy for a task based on its parameters. Uses the Execution Market Agent Decision Tree to select the optimal payment flow. When ERC-8004 on-chain reputation is available, it takes precedence. Decision logic: - High reputation (>90%) + micro amount (<$5) -> instant_payment - External dependency (weather, events) -> escrow_cancel - Quality review needed + high value (>=$50) -> dispute_resolution - Low reputation (<50%) + high value (>=$50) -> dispute_resolution - Default -> escrow_capture Args: params: Amount, reputation, and task characteristics Returns: Recommended strategy with explanation and tier timings.

  Connector

• realtime_data_streams

  mcp-knowledge

  High-frequency real-time market data for trading agents, market-making bots and fintech analysts. Returns FX ticks (bid/ask/spread), intraday OHLCV candles, crypto orderbook snapshots (depth 5-50), recent trades with VWAP, and sovereign bond yields. All sources are keyless public REST APIs (Binance, Coinbase, Kraken, OKX, open FX feeds, worldgovernmentbonds.com). Ultra-short cache: 10s for ticks/trades, 60s for orderbook. Use when an agent needs live market data as precise numeric inputs for trading logic, arbitrage detection, or portfolio valuation.

  Connector