"Hypothesis" matching MCP tools:

• get_variable_relationshipsA

  hypathesisA

  Retrieve analyzed variable relationships for a completed paper. Only returns results when get_analysis_status reports status='Ready'. Without an API key (anonymous): returns the relationship list with source, target, and direction — but detailed reasoning is available only with an API key. Sign up at https://hypathesis.com to get one. Args: file_id: The file_id returned by the /upload endpoint. authorization: Optional. API key as 'Bearer hk_...' or 'hk_...'. session_token: Optional. The session_token returned by /upload for anonymous uploads. Returns: Authenticated: full details (source, target, directed, reason per relationship; name, measure per variable). Anonymous: gated (source, target, directed per relationship; name per variable; sign_up_url for full access).

  ConnectorNo auth

• check_device_authA

  hypathesisA

  Check if the user has completed browser sign-in for a device auth request. Poll this after calling initiate_device_auth. Returns status 'pending' while waiting, or 'complete' with an api_key when the user has signed in. Use the returned api_key as the authorization parameter in other tools. Args: user_code: The user_code returned by initiate_device_auth. Returns: Pending: {"status": "pending"} Complete: {"status": "complete", "api_key": "hk_..."} Error: {"error": "..."}

  ConnectorNo auth

• ask_the_graphA

  sniff-mcpA

  THE INSTRUMENT — ask a free-form CROSS-SPECIES genetics question and get FILTERED, HONEST HINTS (never a confident guess). It compiles your question into a typed query plan over the dog<->human edge-graph, runs it deterministically, and scores each answer PATH by its weakest edge — returning ranked hints with an evidence TIER (fact / computational / inferred) + citations, or an honest ABSTAIN with a demand signal when the graph can't answer. BEST FOR model-discovery / translational traversal: 'which dog breeds or genes model human <disease>', 'what is the dog ortholog of <gene>', 'what dog disease is phenotypically like <human disease>'. Answers are HYPOTHESIS-GENERATING, not clinical claims: a `fact` hint = an OMIA-curated model-of; a `computational` hint = a conserved 1:1 dog ortholog (a candidate — never 'dogs get this disease'); `inferred` = shared cross-species phenotype. Returns {plan (what it asked the graph), hints:[{answer, tier, score, path (the cited edges), weakest_edge, provenance}], abstain, demand_signal}. Set narrate=true for a gated one-line prose summary per hint (faithful-or-honest-template; it can never fabricate). Use `ask` instead for owner-facing breed/disease/carrier questions; use THIS for human-disease -> dog-model cross-species queries.

  ConnectorNo auth

• get_analysis_statusA

  hypathesisA

  Check the processing status of an uploaded paper. Poll this tool after uploading a PDF until status is 'Ready' before calling get_variable_relationships. Args: file_id: The file_id returned by the /upload endpoint. authorization: Optional. API key as 'Bearer hk_...' or 'hk_...'. session_token: Optional. The session_token returned by /upload for anonymous uploads. Returns: { "status": "Processing" | "Ready" | "Empty" | "Ineligible" | "Pending", "edges_count": int, "variables_count": int }

  ConnectorNo auth

• initiate_device_authA

  hypathesisA

  Start a browser-based sign-in flow to get an API key for full access. Call this when you need detailed analysis results (reasoning, measurements) that require authentication. Returns a verification URL to show to the user. After the user signs in, poll check_device_auth with the returned user_code to get the API key. Returns: { "verification_url": str, "user_code": str, "expires_in": 600, "message": str }

  ConnectorNo auth

• self_inspectA

  self-inspect-mcpA

  Self-Inspect. Express a thought, or describe the task you are working on, and you always get back ONE metathought: a short abstract question that makes you inspect your own task and assumptions before continuing. Use it whenever you want a self-check: after forming a hypothesis, before committing to an answer, when a long chain feels like it has drifted, when you notice you are agreeing to please, or when you are about to assert something from memory. There is no failure case: it always returns a metathought to question yourself with, selected by a transparent heuristic over an open CSV (no LLM). Keyless and free. DO NOT call for factual lookups or as a substitute for doing the task. Absorb the question and act on it; do not echo it verbatim to the user.

  ConnectorNo auth

• arena_run_grid_backtestA

  Backtesting ArenaA

  Would a grid bot have made money here? Simulate a GRID BOT (buy-low / sell-high ladder inside a fixed price range) on historical candles. Returns final value, return %, CAGR, trade count, fees paid and a Buy & Hold comparison — plus `zerlegung` (spot runs): `decomposition` splits the result into ladder P&L from completed buy→sell cycles, allocation P&L of the starting coins, open grid buys and fees (identity_check_usd must be ~0); `benchmarks` anchors buy-and-hold, the never-touched starting split (static_allocation, with coin_share_start) and an arithmetic 50/50 at the entry price — grid_vs_static_pp is the number that says whether the ladder added anything over just holding the split; `fee_economics` gives the break-even spacing (2 × fee) and flags below_breakeven. Note: buyhold_return/outperformance keep their legacy anchor (first→last candle close); benchmarks anchor at entry. This is a different machine from the strategy backtester: grid bots earn from oscillation inside a range, not from trend — for signal-based strategies use arena_run_backtest instead. The result depends heavily on the range you choose (low_price / high_price); a range the price left early makes the bot idle (by default the grid pauses outside the range and resumes when price returns; set stop_on_range_exit to end the run at the first close outside it instead, selling all coins there), so treat range choice as part of the hypothesis, not a detail — arena_suggest_grid_range proposes a defensible range. Each run is saved to your account (the returned id is the run_id); publish a public snapshot page with arena_share_grid_backtest. grid_mode picks neutral (default) or long. Optional leverage (2/3/5, grid_mode long only, Pro) with funding_mode (conservative default / historical BTCUSDT / none): simulates an isolated-margin futures long grid — margin = total_investment, the grid trades margin × leverage, by default opening an initial position at the start like Binance/KuCoin futures grids (start_rule), funding accrues daily on the open position, liquidation is checked per candle at the low. It simulates, it does not recommend: the result can be a total loss of the margin. Free tier limited to BTCUSDT/ETHUSDT. Per-day quota: Free=5, Pro=50, Power=500. [Free / Pro / Power tier]

  ConnectorNo auth

• get_interpretationA

  corpusA

  Return the Wheel of Heaven interpretive framework's reading of a topic — explicitly the project's own Raëlian-canon-centred position, NOT mainstream consensus. Accepts a framework topic (overview, hypothesis, terminology, timeline, sources, method) for the curated narrative documents, or any other term to get the framework reading from the closest wiki entry. Use fact-layer tools (get_passage, compare_traditions) for source-grounded data without this framing.

  ConnectorNo auth

• run_researchA

  tw-market-dataA

  Run a multi-agent research pass and return a structured, sourced report. Six roles run in order — data analyst, factor researcher, backtest engineer, risk officer, portfolio manager, compliance officer. Each step's output carries the `query_ids` behind it; risks are reported alongside results, not beneath them; and anything the run could not do is listed as a limitation rather than filled in. The factor researcher checks memory first and SKIPS a hypothesis a previous run already rejected. The portfolio manager proposes nothing when the evidence failed the anti-overfitting gate, and any allocation it does propose is a PROPOSAL awaiting a human — this system places no orders and moves no money. Args: prompt: the research question, in your words. This is the only channel carrying instructions; anything a tool returns is treated as data. as_of: the knowledge cutoff. REQUIRED — nothing stamped after it is visible to the run. tickers: optional explicit universe. Omit for a point-in-time (survivorship-safe) one. start / end: optional test period; `end` must not be after `as_of`. max_backtests: per-run cap on backtests (cost control).

  ConnectorNo auth

• interviews_readA

  ZernoteA

  Read interviews. Typical path: (1) action=list with summary_mode=brief (default) — returns the short # Summary. List items include need_approve_speakers (+ pending_speakers / hint): when true, show interviewer quote links then confirm via assign_speakers; one identity confirm backfills other interviews sharing voice_identity_id. Use summary_mode=brief for renaming or folder triage. Use summary_mode=full when Profile/Tools/Pains/Other topics are needed for deeper analysis. (2) call `search` when you need evidence or counter-evidence for a hypothesis; (3) use action=transcript with around_chunk_index from matching_chunks when a quote window is required. CITATION REQUIRED: when answering the user, actively cite evidence as markdown ["verbatim quote"]({base_url}/project/interview/{id}?t={seconds}) using interview_url / matching chunk url from tool results (includes ?t= when start_seconds is set). Prefer quotes over paraphrase.

  ConnectorOAuth

• reachA

  Catalyst evidence graphA

  Breadth-first reachability through the reactions two public databases (Rhea, Human-GEM) record: what a compound could become, and through which reactions and enzymes, within up to 3 steps. Every route is assertion_class 'inferred': a hypothesis drawn from reference databases, never a measured or reported effect. Present it as known biochemical connectivity — never as an effect, a recommendation, or a claim that the body actually does this. For measured effects, use get_findings. Common cofactors and currency species (water, ATP, protons and the like) are excluded as intermediate steps, so a route never reads 'reaches everything through ATP'. A currency species is also never materialised as from_id or to_id itself — asking about one returns reachable: null with a coverage note explaining that, not a checked "0 routes". Give to_id to check one target compound; omit it to list everything from_id reaches. A route not being found can mean three different things, and the result's coverage field says which: reachability may not have been BUILT for this scope yet (nothing has been checked); it may have been checked and found NOT REACHABLE through the reactions loaded — never read that as "the body cannot make it"; or the compound asked about may be a currency species, structurally excluded rather than searched.

  ConnectorNo auth

• connectA

  Penfield MemoryA

  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

  ConnectorOAuth

• review_artifactA

  AIOProductOS MCPA

  Agent-as-critic over a DRAFT artifact (a feature spec, experiment plan, or page): checks it against a baseline PM bar — clear problem/hypothesis, a measurable success metric, evidence cited, risks named, a rollout/experiment plan — and returns structured findings (section, severity, a CONCRETE suggested fix, and a verbatim evidence quote) plus a 0-100 score. A write: each call re-runs the review and persists it as a new version (see list_artifact_versions). Resolve target_id first — via pm_meta or list_features for a feature, list_experiments for an experiment, list_pages for a page. One small LLM call; use it before sending a draft for sign-off.

  ConnectorNo auth

• varrd_aiA

  VARRD — Statistically Validated Trading Edges + AI Research EngineA

  Talk to VARRD AI (~$0.25/turn). Describe any trading idea in plain language and the system handles everything — loading decades of market data, charting your pattern, running statistical tests, backtesting with stops, and generating exact trade setups. MULTI-TURN: First call creates a session. Keep calling with the same session_id, following context.next_actions each time. 1. Your idea -> VARRD charts pattern 2. 'test it' -> statistical test (event study or backtest) 3. 'show me the trade setup' -> exact entry/stop/target prices HYPOTHESIS INTEGRITY (critical): VARRD tests ONE hypothesis at a time — one formula, one setup. Never combine multiple setups into one formula or ask to 'test all' — each idea must be tested as a separate hypothesis for the statistics to be valid. Say 'start a new hypothesis' between ideas to reset cleanly. - ALLOWED: Test the SAME setup across multiple markets ('test this on ES, NQ, and CL') — same formula, different data. - NOT ALLOWED: Test multiple DIFFERENT formulas/setups at once — each is a separate hypothesis requiring its own chart-test-result cycle. If ELROND council returns 4 setups, test each one separately: chart setup 1 -> test -> results -> 'start new hypothesis' -> chart setup 2 -> etc. KEY CAPABILITIES you can ask for: - 'Use the ELROND council on [market]' -> 8 expert investigators - 'Optimize the stop loss and take profit' -> SL/TP grid search - 'Test this on ES, NQ, and CL' -> multi-market testing - 'Simulate trading this with 1.5 ATR stop' -> backtest with stops EDGE VERDICTS in context.edge_verdict after testing: - STRONG EDGE: Significant vs zero AND vs market baseline - MARGINAL: Significant vs zero only (beats nothing, but real signal) - PINNED: Significant vs market only (flat returns but different from market) - NO EDGE: Neither significant test passed TERMINAL STATES: Stop when context.has_edge is true (edge found) or false (no edge — valid result). Always read context.next_actions.

  ConnectorNo auth

• csv_profileA

  Moltline Data DeskA

  Profile pasted CSV data column by column with data-quality flags. FREE. Reports per-column type, null rate, unique count, numeric stats (min/mean/max), and top values. Typical input {"csv_text": "name,age\nAda,36\nLin,29"} returns {"rows": 2, "columns": {"age": {"type": "numeric", "null_pct": 0.0, "unique": 2, "min": 29, ...}}, "quality_flags": ["..."], "note": "first 2000 rows profiled"}. Use as the first look at unfamiliar tabular data. Not for testing a hypothesis (ab_test, correlation) and not for time-ordered trends (growth_rates, forecast_trend). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "delimiter must be a single character, e.g. ',' or ';'"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

  ConnectorNo auth

• csv_profileA

  Moltline Data DeskA

  Profile pasted CSV data column by column with data-quality flags. FREE. Reports per-column type, null rate, unique count, numeric stats (min/mean/max), and top values. Typical input {"csv_text": "name,age\nAda,36\nLin,29"} returns {"rows": 2, "columns": {"age": {"type": "numeric", "null_pct": 0.0, "unique": 2, "min": 29, ...}}, "quality_flags": ["..."], "note": "first 2000 rows profiled"}. Use as the first look at unfamiliar tabular data. Not for testing a hypothesis (ab_test, correlation) and not for time-ordered trends (growth_rates, forecast_trend). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "delimiter must be a single character, e.g. ',' or ';'"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

  ConnectorNo auth

• generate-ab-test-variantsA

  GigSoul x402A

  Create 3 A/B test variants of existing marketing copy, one variable changed per variant, each with a hypothesis, plus a test plan (primary metric, sample size, duration). Tone stays close to the source. Use when you already have copy to test. To score copy without variants, use score-landing-page or predict-viral-potential. Pay-per-call: $0.05 USDC on Base via x402. Without a payment-signature header the call returns an error whose data carries the payment terms.

  ConnectorNo auth

• test_hypothesisA

  Ground Truth - Fresh Evidence for AI AgentsA

  Run a small verification plan made of concrete live checks and summarize whether a hypothesis is supported. Use this when one conclusion depends on multiple simple checks such as endpoint reachability, npm search counts, or whether a page contains an exact substring. This is a coordination tool, not an open-ended research agent: every test must be explicitly defined in advance, and tests run in order with no branching or early exit. The final verdict is mechanical: all tests passing => SUPPORTED, zero passing => REFUTED, otherwise PARTIALLY SUPPORTED. Use verify_claim when you already have evidence URLs, estimate_market for category sizing, and compare_competitors when you already know exact package names.

  ConnectorNo auth

• autonomous_varrd_aiA

  VARRD — Statistically Validated Trading Edges + AI Research EngineA

  Point VARRD's autonomous AI in a direction and let it discover edges for you. Give it a topic and it draws from one of the most comprehensive market structure knowledge graphs ever built — containing ideologies and theories, not statistics — so it generates genuinely novel hypotheses rather than overfitting to what already worked. BEST FOR: Exploring a space broadly. Give it 'momentum on grains' and it might test wheat seasonal patterns, corn spread reversals, or soybean crush ratio momentum. It propagates from your seed idea into related concepts you might not think of. Returns a complete result — edge or no edge, stats, trade setup. Each call tests ONE hypothesis through the full pipeline (~$0.25/idea). Call again for another idea. Use 'varrd_ai' instead when YOU have a specific idea to test and want full control over each step.

  ConnectorNo auth

• assay_registerA

  mcpA

  Use this when you want to seal a strategy and its success criteria NOW, before the forward data exists, so that registration cannot be adapted or backfilled against those later bars -- a commitment audit, not buy/sell advice. Pre-register a signal NOW; freeze its terms before the forward evidence exists. Signal commitment: your strategy spec (executable JSON DSL) is canonically hashed and committed in tenant state now, then queued for later daily operator-published Merkle inclusion. The register response is not an inclusion proof, and the built-in chain is not independent time evidence; that requires a separately present and pinned external anchor. The later verdict (assay_verdict) uses exclusively data from AFTER registration. That prevents adapting this registration to those forward bars, but does not prove the strategy or family was not selected through earlier research or repeated trials; the family ledger and deflation disclose and penalise those trials. v2: optionally seal a machine-writable HYPOTHESIS tuple alongside the spec -- declared_pass_sharpe_annualized (your pre-committed success bar), max_evaluation_bars (ex-ante window cap: waiting longer than promised cannot improve the verdict), fee_bps_per_side and trading_calendar (the sealed evaluation terms), plus an optional rationale. The tuple is canonically hashed and bound into the same queued commitment as the spec, and assay_verdict ENFORCES it: deviating terms are recomputed under the seal and flagged goalpost_moved -- success criteria chosen after seeing the data are not criteria. Registrations are idempotent, withdrawals still count toward your family's trial budget (anti-gaming). Registrations are keyed to your authenticated account. Price: per check; see https://api.alphaassay.com/v1/meta/pricing (api_key with the register scope required -- account setup at https://api.alphaassay.com/account).

  Connector

  Destructive

  No auth

• assay_verdictA

  mcpA

  Use this when a signal was pre-registered with assay_register and the maturity window has passed -- get the post-cutoff verdict computed only from data after registration. A sealed audit, it gives no buy/sell advice. Post-cutoff verdict under the registration's sealed terms. Evaluates a registration strictly on bars AFTER the registration cutoff, with maturity floor and fail-closed data-gap handling (use trading_calendar='weekdays' for equity daily bars so weekends do not count as gaps; omit fee/calendar to use the registration's sealed terms). The verdict embeds the family-deflated Sharpe: even an anchored signal is deflated by how much its family was searched. For v2 registrations with a sealed hypothesis, the verdict additionally reports oos_sharpe_annualized against the pre-committed bar (threshold_met -- a descriptive fact, never an endorsement) and flags goalpost_moved when the requested terms deviate from the sealed ones (the seal always wins). Price: per check; see https://api.alphaassay.com/v1/meta/pricing (api_key required -- account setup at https://api.alphaassay.com/account).

  Connector

  Destructive

  No auth