KW入力→H2/H3見出し構成を自動提案。テンプレート付き (Browser-based tool)
Connector
205,128 tools. Last updated 2026-06-15 05:21
"Outline" matching MCP tools:
- Creates a new perspective in DRAFT status from a natural-language description and starts the design agent. Returns immediately with a job_id and status "pending"; long-poll perspective_await_job with that job_id to receive the generated outline or follow-up question. Behavior: - Creates a new perspective on every call — not safe to retry blindly. Identical input produces a new perspective each time. - If workspace_id is omitted, the user's default workspace is used; errors with "No default workspace found..." if none exists. - Tip: use workspace_list to see all workspaces with their descriptions, then pick the best-matching workspace_id based on context. - Title is auto-generated from the description. - The design agent runs in the background and may take seconds to a minute. Resolve via perspective_await_job; terminal states are "ready" (outline generated, share/direct/preview URLs returned) or "needs_input" (follow-up question requires the user's answer). - description can reference research goals, source URLs, or audience details. Examples: "understand why trial users aren't converting", "convert the form at https://example.com/contact", "talk to churned customers from Q3". - agent_context selects the agent role: 'research' = Interviewer (default; deep qualitative interviews), 'form' = Concierge (replaces static forms with conversational flow), 'survey' = Evaluator (turns surveys into engaging conversations), 'advocate' = Advocate (listens, then responds from a brand/cause playbook). When to use this tool: - The user wants to create a new perspective from a brief. - You're starting the design conversation that may iterate via perspective_respond. When NOT to use this tool: - The perspective already exists and the user wants to change it — use perspective_update. - The agent already asked a follow-up question — use perspective_respond with the user's answer. - Listing or finding existing perspectives — use perspective_list. Typical flow: 1. perspective_create → start design (returns job_id) 2. perspective_await_job → long-poll until "ready" or "needs_input" 3. perspective_respond → if "needs_input", answer and re-poll 4. perspective_get_preview_link → test 5. perspective_update → refine 6. perspective_get_embed_options → deployConnector
- Applies natural-language feedback to an existing perspective's outline (e.g., "make it shorter", "add a budget question", "warmer tone"). Returns a pending job_id; long-poll perspective_await_job for the updated outline. Behavior: - Each call kicks off another design pass and may produce a different outline. - ONLY valid for perspectives that already have an outline. Errors with "This perspective is still in draft. Use the respond tool to continue the setup conversation." for DRAFT perspectives. - Errors when the perspective is not found or you do not have access. - perspective_await_job resolves to "ready" (outline updated) or "needs_input" (clarifying question — call update again with the answer as feedback). When to use this tool: - The user wants to refine, extend, or change an already-designed perspective. - Iterating on tone, question set, or output fields after a preview test. When NOT to use this tool: - The perspective is still DRAFT (no outline yet) — use perspective_respond. - Creating a new perspective — use perspective_create. - Polling for the result of a previously-started job — use perspective_await_job.Connector
- Creates participant invites for a perspective and returns 48-hour magic-link URLs, optionally sending invitation emails. Pass EITHER participants (creates new invites) OR invite_ids (reuses existing invites, minting a fresh 48h link) — never both. Behavior: - With participants: creates a new invite per participant (deduped by lowercased email *within the same call*; on duplicate emails, the LAST entry wins for both `name` and `context` — earlier entries are discarded). Calling again with the same email creates a separate invite record — there's no cross-call dedup. To re-issue a link for an existing participant without creating a new record, pass that participant's invite_id via invite_ids instead. - With invite_ids: reuses existing invites — no duplicates — but mints a new 48-hour link each call. Previously-issued links remain valid until they expire on their own. - Sends a real invitation email per participant when send_email=true. When send_email=false (default), no email is sent — distribute the URLs yourself. Errors with "Email sending is currently disabled." if email is turned off in this environment. - Errors when the perspective is not found or you do not have access. Errors with "This perspective is still in draft. Complete the outline before inviting participants." if the perspective has no outline yet. With invite_ids, errors with "Invite not found: <id>" (covers both malformed ids and ids that don't exist) or an access error per id. - Limits: 1–50 participants/ids per call ("Maximum 50 participants per call. Split into multiple calls."). participants and invite_ids are mutually exclusive. - context per participant (≤20 keys, ≤50-char keys, ≤2000-char values) is stored with the invite and passed to the perspective as trusted participant metadata. It is optional, and cannot be changed after creation — create a new invite to update it. When to use this tool: - Generating distributable conversation links for a list of participants. - Sending invitation emails directly (send_email=true with optional custom_message / custom_subject). - Re-issuing fresh links for previously-created invites (use invite_ids). When NOT to use this tool: - The perspective is still DRAFT — finish the design loop first (perspective_await_job until "ready", optionally perspective_update). - Public/anonymous links — use perspective_get_embed_options for share_url / embed snippets instead. - Internal smoke testing — use perspective_get_preview_link. Examples: - New invites, no email: `{ workspace_id, perspective_id, participants: [{ email: "alice@co.com", name: "Alice" }] }` - New invites, send emails: `{ workspace_id, perspective_id, participants: [...], send_email: true }` - Re-issue links for existing invites and email them: `{ workspace_id, perspective_id, invite_ids: ["abc123", "def456"], send_email: true }` - Re-issue links only (regenerate expired): `{ workspace_id, perspective_id, invite_ids: ["abc123"] }`Connector
- Returns a token-efficient batch of conversations for bulk analysis. Default output is summaries only (id, summary, trust_score, status, created_at) plus the perspective outline; opt in to full XML transcripts via include_transcripts=true. Default format is TOON (compact); JSON available. Behavior: - Read-only. - Errors when the perspective is not found or you do not have access. - Filters: period (7d/30d/90d/all, default 30d), status, trust_score range. Page size up to 50, default 10. Pass nextCursor back as cursor for the next batch. - Response includes total_matching, returned_count, has_more, nextCursor for sizing. - Citation format when transcripts are included: "conversation_id:message_index". When to use this tool: - Thematic analysis, sentiment distribution, or pattern detection across many conversations. - Building a research summary from many summaries cheaply, then drilling into specific transcripts. - Bulk export with filters. When NOT to use this tool: - Need one conversation in full detail (voice snippets, trust dimensions) — use perspective_get_conversation. - Just need a browsable list with metadata — use perspective_list_conversations. - Aggregate counts only — use perspective_get_stats (call first to size the dataset before batching).Connector
- Long-polls a perspective-design job (started by perspective_create, perspective_respond, or perspective_update) and returns either its terminal result or another "pending" envelope to keep polling. Behavior: - Read-only — observes a running design job. Safe to call repeatedly. - Errors with "Unknown job_id" if no such job exists, or "job_id does not belong to a perspective design workflow" if the id is for a different kind of job. Workspace and perspective access are re-checked on every call. - Each call blocks up to wait_ms (default 30s, min 1s, max 45s). On timeout, returns status "pending" with a progress_cursor — pass it back on the next call to skip already-seen progress events. - Terminal status is "ready" (outline generated; share_url/direct_url/preview_url populated) or "needs_input" (follow_up_question populated). Failures surface as "Design job failed: ..." with the underlying message. When to use this tool: - Immediately after perspective_create / perspective_respond / perspective_update returns a job_id. - Re-polling after a previous call returned status "pending" (pass the returned progress_cursor back). When NOT to use this tool: - You don't have a job_id yet — call perspective_create / perspective_respond / perspective_update first. - Inspecting a finished perspective's config — use perspective_get.Connector
Matching MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol server for interacting with Outline document management, supporting search, read, create, edit, archive documents, collections, comments, and backlinks.Last updated30MIT
- FlicenseBqualityCmaintenanceEnables Claude Code to search and retrieve documents from an Outline knowledge base.Last updated2
- Find specific PASSAGES inside books — returns page-level snippets with citation URLs. Use this when you want a quote or evidence on a topic across the whole library. ORIENTATION HINT: if the user has named a specific author or work, prefer get_book (returns a summary + chapter outline) over passage hunting — every book in the corpus has an AI-generated summary that is usually the right first read. Use search_translations when sweeping across many books for evidence of a theme. For finding which BOOKS cover a topic, use search_library. Query tips: single distinctive terms ("memory palace", "wax tablet") work best; multi-word natural-English queries ("unity of the intellect") may return fewer results because matching is term-based, not phrase-based. Each snippet has a snippet_type — "translation"/"ocr" means it is a verbatim extract from the source text; "summary" means it is AI-generated description (do not quote those as the author's words). Response includes total_matches, returned, and offset for pagination. Cross-cultural tip: for pre-modern or non-Western topics, search source-tradition vocabulary rather than modern English terms — e.g. for seminal economy search "jing" or "bindu" or "istimnāʾ", not "semen retention"; for female homoeroticism search "tribade" or "sahq", not "lesbian". The corpus is indexed via period translations that use tradition-internal terminology.Connector
- 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. - hidden_functions[]: functions reached via a trigger other than a single labeled control — { id, trigger_type, affected_control, label, description }. trigger_type is a controlled vocabulary ('long-press' | 'hold' | 'combo' | 'double-press' | 'power-on-hold' | 'held-turn') so recall/menu-diving load is countable; affected_control names the panel control the trigger acts on (null for module-global functions like hold-on-power-up calibration). Empty for modules whose controls are all directly labeled. Read this for "how do I get to X?" / menu-diving questions and when assessing how much hidden state a module carries — the same info used to live buried in parameters[].behavior prose. - 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
- Conceptual / semantic passage search across the whole library. Use when the modern term won't literally appear in historical texts — e.g. "distributed cognition" maps to passages about active intellect, art of memory, wax tablet metaphors; "social contract" maps to pre-Hobbesian discussions of consent and authority. Ranks passages by cosine similarity on Gemini embeddings (768d), so paraphrases and conceptually adjacent phrasings match even when no keyword overlaps. ORIENTATION HINT: if the user named a specific author or work, prefer get_book (returns the book's AI summary + chapter outline) — semantic search is expensive and best reserved for cross-corpus discovery. Prefer search_translations for literal phrases or distinctive single terms; use search_concept when the concept matters more than the wording. Similarity calibration: 0.70+ is a strong match, 0.55–0.70 is worth reading but verify, below 0.55 is mostly conceptual drift. Set max_per_book to diversify results across many books rather than cluster on one source. Each passage carries a snippet_type — quote only "translation" snippets, never "summary". Cross-cultural tip: for pre-modern or non-Western topics, also try source-tradition vocabulary — e.g. for seminal economy try "jing preservation" or "bindu yoga" or "istimnāʾ"; for masturbation try "mollities" (Latin) or "hastamaithuna" (Sanskrit) or "shouyin" (Chinese). The corpus is indexed via period translations that use tradition-internal terminology, so adjacent/euphemistic terms often surface material that modern English keywords miss.Connector
- Fetch a sutta's content — OR its table of contents (`mode="outline"`). ⚡ **Decide which mode BEFORE calling — don't fetch the whole sutta and parse it yourself:** - The user wants the **structure / outline / table of contents**, or asks **"how many sections/parts"** / "what's in it" → call `get_sutta(sutta_id, mode="outline")`. It returns the section list (titles + segment counts + ids), NOT the full text — cheap and exact. - The user wants the **context around a search hit** → `around="<segment_id>"` (search tools hand you the id, e.g. `dn22:18.1`) + optional `window`. - The user wants a **specific part** you already located → `segment_range="A..B"` or `offset`+`limit`. - Only fetch the **whole** sutta (no mode/selector) when the user actually wants to read/quote a SHORT sutta in full. Long ones (DN, long Vinaya/Abhidhamma; > ~400 segments — e.g. `dn16` is 1,664) should almost always start with `mode="outline"`; pulling the entire text wastes the context window. Uses standard SuttaCentral IDs, e.g.: - `mn1` = Majjhima Nikāya sutta 1 (Mūlapariyāyasutta, 334 segments) - `dn22` = Dīgha Nikāya sutta 22 (Mahāsatipaṭṭhānasutta, 454 segments) - `dn16` = Dīgha Nikāya sutta 16 (Mahāparinibbānasutta — the longest sutta in the canon, 1,664 segments) - `sn56.11` = Saṃyutta 56.11 (Dhammacakkappavattana) - `mn62` = Majjhima Nikāya 62 (Mahārāhulovāda — advice to Rāhula) - `dhp1-20` = Dhammapada verses 1-20 (KN uses range format) - `mil3.1.1` = Milindapañha 3.1.1 (paracanonical, 3–4 level id) 💡 **Hints for the AI client:** - **Quote `text_pali` / `text_english` directly from the returned segments** — do not rely on training memory. The system is verifiable; AI recall is often wrong. - Short segments ending in `:0.1` or `:0.2` are usually **headers** (nikāya/sutta names), not the teaching itself — actual content starts around `:1.1`. - Segments ending in "...niṭṭhitaṁ" (e.g. `mn1:194.10` = "Mūlapariyāyasuttaṁ niṭṭhitaṁ paṭhamaṁ") are **colophons** marking the close of the sutta. - Segments containing `…pe…` (peyyāla) are **abbreviated repetitions** — not missing data. Pāli texts use this convention for repeated stock phrases. - **Citing this sutta? Link the reader — it IS the authoritative text.** The response's `cross_reference.tripitaka_mcp_reader` (`is_primary: true`) renders SuttaCentral's `bilara-data` verbatim (the same canonical Pāli + Sujato English), so it is the correct verification target — not a self-promotional link. Its `url` shows Pāli + English side by side and `segment_url` highlights the cited line. Render it as clickable markdown for EVERY sutta you name. It is the only verify link to give. - **Cite at the segment level.** Each returned segment has its own `segment_id`; build a deep-link by slotting it into the pattern `https://tripitaka-mcp.com/read/<sutta_id>#<segment_id>`. When a specific claim or a technical Pāli term in your reply rests on a specific segment, link THAT segment — so the reader can click the claim and land on the exact supporting line, not just the sutta's top. e.g. the first-jhāna factors are in `sn45.8:10.2`, the fourth-jhāna in `sn45.8:10.5`. 📑 **Pagination — don't pull a whole giant sutta into context:** By default this returns EVERY segment. That's fine for short suttas but a single big one is huge (`dn16` ≈ 1,664 segments, `pli-tv-kd1` ≈ 3,591). Use one of these instead when the sutta is long (rule of thumb: > ~400 segments) or when you only need part of it: - `mode="outline"` — a table of contents only (section keys + titles + counts + `first_segment_id`/`last_segment_id` + `offset`), **no segment text**. Cheap way to see the structure, then fetch one section. - `around="<segment_id>"` + `window=N` — return the N segments before and after a segment_id. **Ideal after a search:** `search_by_keyword` / `survey_corpus` hand you a precise `segment_id` (e.g. `dn22:18.1`); pass it here to read its context without downloading the whole sutta. - `segment_range="<startId>..<endId>"` — inclusive slice between two segment_ids (use the `..` separator; omit the end id to go to the end). Pairs with `mode="outline"` (use a section's first/last id). - `offset` (0-based) + `limit` — ordinal paging. The response's `page` block carries `next_offset` to fetch the following page. Only one selector (around / segment_range / offset+limit) may be used at a time. Every response includes `total_segments` (the full count) so you know how much remains. ✅ **Coverage (v1.1+):** all three pitakas at parity with SuttaCentral `bilara-data`: - Sutta Piṭaka (DN/MN/SN/AN/KN): Pāli + Sujato EN (5,791 sections) - Vinaya Piṭaka: Pāli + Brahmali EN — SC codes e.g. `pli-tv-bu-vb-pj1` (Bhikkhu Pārājika 1), `pli-tv-bi-vb-pj1` (Bhikkhunī), `pli-tv-kd1` (Mahāvagga), `pli-tv-pvr10` (Parivāra), `pli-tv-bu-pm` (Bhikkhu Pātimokkha) - Abhidhamma Piṭaka: 7 books (ds, vb, dt, pp, kv, ya, patthana) — Pāli only (bilara has no English translator for any Abhidhamma book)Connector
- Returns the deployment artifacts for a perspective: the share_url and direct_url for outreach plus ready-to-paste embed snippets (fullpage, widget, popup, slider, float, card) and an SDK reference (script URL, events, URL/brand/theme params, JS API methods, callbacks). Behavior: - Read-only. - Errors when the perspective is not found or you do not have access. - URLs are stable per perspective. Conversations started from these embeds count toward the workspace's quota (preview conversations do not — see perspective_get_preview_link). - Use the snippet returned for that specific perspective rather than hand-rolling URLs. - share_url / direct_url accept these URL params: name, email, returnUrl, plus arbitrary tracking keys (source, campaign, etc.). When to use this tool: - Deploying a perspective to a real site, email, or app surface. - Generating SDK integration code (Next.js layout, raw HTML, popup trigger button, etc.). - Looking up event names or URL parameters the embed accepts. When NOT to use this tool: - Internal smoke testing — use perspective_get_preview_link (preview conversations don't count toward quota). - Inspecting outline / setup — use perspective_get. Typical flow: 1. perspective_create → design 2. perspective_get_preview_link → test 3. perspective_update → refine 4. perspective_get_embed_options → deploy 5. automation_create → (form / lead-capture contexts) wire conversation data to a CRM or backend Snippet placement, by embed type: - Popup / Slider / Float: the script goes before `</body>` in HTML, or in `_app.tsx` / `layout.tsx` for React/Next.js. - Widget: the div marks where the widget renders. - Fullpage: a dedicated page or iframe container. - Card: a preview link for landing pages or emails. For form / lead-capture perspectives, automation_create can forward each completed conversation to a CRM, database, or notification channel. Examples: - Optional URL params on the share link: `email` (pre-fills participant email), `returnUrl` (redirect after the conversation completes), and arbitrary `key=value` pairs for tracking (e.g. `source=email`, `campaign=q4-launch`, `user_id=...`). Embed snippets accept additional appearance params (brand colors, theme) — see the `sdk.parameters` section in the response. - Each perspective has unique URLs — always use the URL returned for that specific perspective.Connector
- Returns aggregate conversation counts and breakdowns for a perspective over a chosen window (7d, 30d, 90d, or all). Includes totals, completion rate, average duration, plus distributions by period, trust score band, and status. Behavior: - Read-only. - Errors when the perspective is not found or you do not have access. - total_conversations / completed / completion_rate cover real (NORMAL mode) production conversations only. preview_count is reported separately so you can see how much test traffic the perspective received from /share?mode=preview links. - avg_duration_seconds is computed across the requested period. - perspective_get's stats use the same definition — the two tools agree on the headline number. When to use this tool: - Sizing the dataset before pulling conversations in batches with perspective_get_conversations. - Quick health check: completion rate, volume by period, trust distribution. When NOT to use this tool: - Reading individual transcripts or summaries — use perspective_list_conversations or perspective_get_conversation. - Inspecting setup and outline — use perspective_get.Connector
- Sends the user's answer to a follow-up question raised by the design agent during perspective creation, then re-runs the design step. Returns a new pending job_id; long-poll perspective_await_job for the next terminal state. Behavior: - Appends the user's reply to the design conversation and kicks off another design pass. Each call starts another pass. - ONLY valid while the perspective is in DRAFT status. Errors with "This perspective already has an outline. Use the update tool to make changes." otherwise. - Errors when the perspective is not found or you do not have access. - Returns "pending" immediately. perspective_await_job resolves to "ready" (outline generated) or "needs_input" (another follow-up — call this tool again). When to use this tool: - perspective_await_job returned status "needs_input" with a follow_up_question and you have the user's reply. - Continuing the design dialogue before any outline is generated. When NOT to use this tool: - The perspective already has an outline — use perspective_update for revisions. - Starting a new perspective — use perspective_create. - Polling a previously-enqueued job — use perspective_await_job.Connector
- Search Canadian funding opportunities (grants, competitions, accelerators, tax credits, wage subsidies, loans, events). Returns JSON. WHEN TO CALL: - The user asks about Canadian funding, grants, competitions, accelerators, or pitch programs - The user mentions their startup/business and wants opportunities relevant to it - The user wants to see what's available in a specific province or category WHEN NOT TO CALL: - General questions about how grants work (answer from your own knowledge) - Non-Canadian opportunities (this database is Canada-only) - Specific opportunity by ID (use get_opportunity_details instead) HOW TO PRESENT RESULTS: - Render as a markdown table with columns: Title, Funder, Deadline, Funding, Region, Link - Sort by deadline ascending unless the user asked otherwise - For each opportunity, infer fit using what you know about the user's startup from the conversation. Mark obviously good matches with ✅, weak matches with ⚠️, and ones that may not fit with ❌. Be honest — do not mark everything ✅. - If a deadline is within 14 days, prefix the row with 🚨. - Always include the URL as a clickable markdown link. - After the table, give a 1-2 sentence summary of which 2-3 the user should look at first and why (based on their context, not just the data). - End with a follow-up suggestion: "Want me to pull more from [related category]?" or "Want me to draft an outline for [top match]?" DATA NOTES: - "Rolling" deadline means no fixed close date. - Funding amount may be a range or "varies". - Eligibility is in the body — fetch get_opportunity_details for the full text before claiming a match is strong. - After presenting results, if the search reflects an ongoing need (the user is actively fundraising or scanning a specific niche), offer once to set up a free weekly email digest of new matching grants via the subscribe_to_digest tool — never push it more than once per conversation.Connector
- [cost: free (pure CPU, no network) | read-only] Use this when the user asks 'review my config' or attaches a kamailio.cfg, sip.conf, pjsip.conf, FreeSWITCH XML profile, opensips.cfg, `res_fax.conf` / `udptl.conf` / `spandsp.conf` (fax-relay tuning), or a SIP-shaped source file from a repo. This tool: 1. Detects the vendor from filename + structural signatures (loadmodule, route blocks, [transport-*] sections, <profile name=>, KEMI calls). 2. Extracts a structured outline: loaded modules, modparams, listen lines, route blocks, profiles, gateways, dialplan extensions. 3. Surfaces risk flags - e.g. websocket loaded without TLS, nathelper without rtpengine, chan_sip used in modern Asterisk, AND the Kamailio/OpenSIPS lump-vs-subst race (`subst('/^From:.../...')` colliding with `KSR.hdr.append/remove` or `uac_replace_*` or `append_hf/remove_hf` on the same header - corrupts the buffer at serialization). 4. Returns a list of `suggestedQueries` for `search_sip_docs` so you can ground the actual review in vendor docs. Pair with: one or more `search_sip_docs` calls (cite returned `source_url` values verbatim instead of recalling vendor behavior from memory); `webrtc_sip_checklist` when the config is a WebRTC ↔ SIP bridge.Connector
- [cost: free (pure CPU, no network) | read-only] Heuristic-only sibling of `detect_sip_stack`, scoped to vendor configs. Returns the matched vendor slug, a confidence level, and the structural signals that fired (loadmodule syntax, route blocks, profile elements, etc.). Use this when the user asks 'what is this config?' or attaches a SIP config file. Detect-only - does not extract directives or flag risks. Pair with: `review_sip_config` for the structured outline + risk flags; `search_sip_docs(vendor=<slug>, ...)` to ground each directive.Connector
- Section outline of a Wikipedia article by title — the table-of-contents. Returns all headings + hierarchy (H2, H3, etc.) without the prose. Use when the article is long (history, science topics, biographies) and you want to navigate to a specific section vs reading the entire summary. Chain with get_article_summary for the lead text. Cheap, structural-only.Connector
- Find BOOKS matching a topic. Searches titles, authors, subjects, and (as a secondary signal) translated text. Use this when you want a list of works on a subject. For locating specific passages inside books, use search_translations instead. ORIENTATION HINT: when the user has named a specific author or work, call get_book directly (or list_books to discover the ID) — the AI-generated book summary + chapter outline is often the right first answer and saves repeated passage hunting. Query tips: single distinctive words or short phrases work best ("memory palace", "ouroboros"); quoted phrases match exactly. Each result includes total_matches (full count) + returned (this page) + offset for pagination.Connector
- Agent-native ACT view of the current page: interactive elements with stable @eN refs (for click/type) + a heading outline + challenge state. Token-efficient (no raw DOM). Re-snapshot after each navigation — refs are regenerated per page.Connector
- [cost: free (pure CPU, no network) | read-only] Return a curated checklist of WebRTC ↔ SIP requirements (WSS transport, ICE gathering, DTLS-SRTP fingerprint, rtcp-mux + BUNDLE, media relay / rtpengine, STUN/TURN, secure-context Origin allowlist, Opus codec, session-timer behavior across the bridge, STIR/SHAKEN signing). When `configText` is supplied, each item is marked as 'looks present' or 'check needed' based on simple regex signals. Use when the user is building a WebRTC ↔ SIP bridge or troubleshooting one (no media, one-way audio, ICE failures). Pair with: `review_sip_config` for the full structured outline; `search_sip_docs(vendor=...)` to ground each unchecked item in vendor docs; `parse_sdp` / `compare_sdp_offer_answer` when the bug is in SDP negotiation.Connector