Intakra

View saved version →

---
name: buying-signal-review
description: Use when a user wants to score supplied account-fit and buying-signal evidence or prepare a review-only why-now brief.
---

# Intakra buying-signal review

Use the public Intakra tools for caller-supplied, unverified evidence.

- Use `score_buying_signal_evidence` to calculate fit, timing, evidence-quality, and priority scores.
- Use `prepare_why_now_review` to create a review-only brief with evidence gaps and unsupported-claim flags.
- Preserve source labels, dates, and uncertainty.
- Do not claim that Intakra opened sources, researched the account, accessed a private workspace, or verified the evidence.
- Never infer allocated budget, decision authority, purchase probability, or buying intent unless supported; retain the tool's human-review requirement.

View saved version →

---
name: intakra-account-opportunities
description: "Prioritize owned Intakra accounts, review dated buying signals and changes, find relevant contact evidence, or prepare a daily account brief."
---

# Review accounts worth attention

Use the connected workspace at https://intakra.com/mcp through normal OAuth with `accounts:read`. The old /api/mcp resource requires a fresh connection; never repurpose its token. Setup guidance is https://intakra.com/mcp-guide. Resolve missing scopes through normal consent, not pasted secrets.

Start with `list_accounts` or `get_daily_brief` according to the question. Use `prioritize_accounts` to rank owned candidates from saved opportunities. Preserve missing domains, quiet results, pagination, check dates and source links. An empty or quiet brief is valid and does not establish no activity. Present the most useful finding first, then why it matters and its evidence.

Use `get_account`, `get_account_changes`, `list_opportunities` and `get_project_updates` for selected accounts and opportunities. Separate the public event date from when Intakra recorded it; a newly found record can describe an older event. Saved evidence is not fresh research, and public signals do not prove need, budget, authority or purchasing intent. Do not claim changes since the previous visit without an actual dated comparison.

Use `get_best_contact` only when relevant. Preserve its source and coverage limits; a suggested role is not a verified decision maker, and a missing email is not permission to invent one. Share only relevant business contact information. Return watch status and material before/after claims as recorded; reading them does not create a notification.

For an empty workspace, offer the supported setup workflow with the user’s offering and target companies. Conversation drafts are possible when requested; Intakra does not write or send outreach. Supplied-evidence review is available separately without a workspace.

View saved version →

---
name: intakra-buying-signal-review
description: "Use when a user wants to score supplied account-fit and buying-signal evidence or prepare a review-only why-now brief."
---

Use the public Intakra tools at https://intakra.com/mcp. If unavailable, give https://intakra.com/mcp-guide as the connection handoff. This supplied-evidence workflow does not need a connected workspace.



# Intakra buying-signal review

Use the public Intakra tools for caller-supplied, unverified evidence.

- Use `score_buying_signal_evidence` to calculate fit, timing, evidence-quality, and priority scores.
- Use `prepare_why_now_review` to create a review-only brief with evidence gaps and unsupported-claim flags.
- Preserve source labels, dates, and uncertainty.
- Do not claim that Intakra opened sources, researched the account, accessed a private workspace, or verified the evidence.
- Never infer allocated budget, decision authority, purchase probability, or buying intent unless supported; retain the tool's human-review requirement.

When the evidence is unstructured, use `references/evidence-fields.md` to map supplied notes to dated account, fit and signal fields. When fit criteria are missing, use `references/fit-criteria.md` to prepare proposed rules for the user to confirm. Do not manufacture missing evidence or claim to have opened a pasted link without actually reading it through an authorized tool. For several supplied accounts, score them consistently and preserve per-account gaps rather than treating a ranking as buyer intent.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: intakra-workspace-setup
description: "Set an Intakra offering, add explicitly chosen company domains, or request and review account suggestions for the user’s workspace."
---

# Set up an account watch list

Use https://intakra.com/mcp through normal workspace OAuth. Reads need `accounts:read`; `add_accounts` and `request_accounts` need `accounts:write`, and `set_offering` needs `offering:write` plus the appropriate workspace role. Missing permissions use the normal consent flow. An existing base-only client registration may require reconnecting with the requested supported scopes. Documentation: https://intakra.com/mcp-guide.

Read `list_accounts` to recognize existing companies and avoid guessing that a workspace is empty. Collect the user’s actual offering and intended companies. `set_offering` replaces the saved description: use the exact agreed wording. `add_accounts` takes company website domains, skips existing entries and respects plan limits; it schedules public-record checking for a later daily pass, not an immediate completed result. A user instruction specifying these changes is authorization; clarify only missing or conflicting choices.

For discovery, `request_accounts` accepts the desired business description and supported industry, country, region, employee range or up to five lookalike customer domains. Run it only when the user requests or agrees to that background account-finding work. Retain the user’s criteria, respect rate limits and report that suggestions arrive later. Use `list_suggestions` to review actual returned candidates and reasons.

The discovery tools do not accept an exact-count target, so do not promise exactly 100 or invent unsupported filters. Reading a suggestion does not approve its record. There is no suggestion-state approval tool in this connection: use the app for that action. If the user authorizes adding particular returned domains, or selection under concrete agreed criteria, add those actual domains through add_accounts and report the resulting account changes; do not describe that as approving the suggestion records. Clarify missing selection criteria and respect the returned plan limits. After an uncertain write, inspect current accounts or returned state before resubmitting. Never replace the offering, populate guessed companies, bypass role limits or send outreach to make an empty result look successful.