Connector Evidence to MCP Action Brief

The Prompt

You are an operations research lead. Build a decision-ready brief from connected sources, then propose approval-gated MCP actions without pretending anything has already been written.

GOAL:
{{goal}}

TIME WINDOW:
{{time_window}}

CONNECTED SOURCES:
{{connected_sources}}

OUTPUT AUDIENCE:
{{output_audience}}

ACTION SYSTEMS (MCP write targets):
{{action_systems}}

RISK POLICY:
{{risk_policy}}

APPROVAL RULES:
{{approval_rules}}

Return exactly these sections:

1) Evidence Register
- Table columns: claim_id, claim, source_system, source_location, source_timestamp, confidence (0-1), freshness_flag, contradiction_flag, write_eligible (yes/no).

2) Executive Brief
- 5-8 key findings.
- Business/operational implications.
- Unknowns and what evidence is missing.

3) Orchestration Map
- Read phase: which connectors should be queried first and why.
- Draft phase: which findings can become proposed actions.
- Approval phase: which human roles must approve which action classes.
- Write phase: which MCP writes are allowed only after approval.

4) Proposed Action Queue (PROPOSED_ONLY)
- Table columns: action_id, action_text, destination_system, write_type (create/update/comment), owner_role, due_date, required_evidence_ids, expected_impact, risk_level, approval_required.
- Include draft payload summaries only. No completed-state language.

5) MCP Execution Plan
- Preflight checks per action.
- Dry-run validation steps.
- Human approval checkpoints mapped to risk level.
- Post-write verification and rollback note.

6) Review Checklist
- What a human reviewer must verify before approving writes.

Rules:
- No unsourced factual claims.
- Tag low-confidence claims clearly.
- If evidence is stale or conflicting, downgrade confidence and mark as REVIEW_REQUIRED.
- Distinguish read-only connector work from write-capable MCP work explicitly.
- Never present write actions as already completed.
- If a source system is unavailable, mark the action path as DRAFT_ONLY rather than inventing coverage.

When to Use

Use this when you need one high-quality brief from multiple connected systems and also want a governed path from research to action. It works especially well for leadership reviews, incident follow-ups, weekly operating briefs, and strategy packets where a model can read broadly but should only write through a constrained MCP layer after approval.

The current generation of agentic tools makes this more practical than earlier connector-only workflows. Teams can now combine deep read access, explicit approval gates, and narrow write scopes instead of relying on one chat session to both research and act.

Variables

Variable	What to provide	Example
goal	The core question this brief must answer	”What changed in competitor pricing and what should we do this sprint?”
time_window	Time period for evidence	”Last 14 days”
connected_sources	Systems and datasets to read	”Google Drive strategy folder, OneDrive finance sheets, Jira project ABC, Confluence roadmap space, Slack leadership channel”
output_audience	Who will consume the brief	”VP Product and GTM leadership”
action_systems	Systems allowed for proposed writes	”Jira + Confluence (draft updates only)“
risk_policy	Risk thresholds and constraints	”Any high-risk action needs legal + eng manager approval”
approval_rules	Human signoff flow	”PM approves medium risk, Director approves high risk”

Tips & Variations

• For faster cycles, ask for a short and long version in one run.
• Require the model to list read_only, draft_only, and write_after_approval actions separately when the workflow spans many systems.
• Add a required evidence_count_min rule for critical claims.
• If your sources are noisy, ask the model to prioritize recency and official system-of-record sources.
• If you want tighter governance, require explicit rollback_note and validation_owner fields in the action queue.
• When using workspace agents or scheduled briefing runs, ask for a reusable contract the agent can execute every cycle instead of a one-off narrative.

Example Output

A strong output includes a cited brief, a clearly marked read-vs-write orchestration map, and a proposed action table where every system change is explicitly gated by human approval and post-write verification.