Build a Claude Cowork Close Plugin: Step by Step

You've read the architecture overview and now you have to actually build the thing. This is the hands-on version: a single engineer sitting down to ship a Claude Cowork plugin that helps a finance team run month-end close, with real file layouts, real connector code, and a real test plan. We'll build a plugin called finance-close that fetches trial balances, reconciles two entities, flags variances, and drafts a close summary — and we'll do it in a way that a controller can trust on day one.

Key takeaways

• A plugin is a directory: a manifest, one or more skills, connector configs, and sub-agent definitions.
• Start with a read-only MCP connector to your warehouse before you let the agent write anything.
• Encode the close procedure as a skill with numbered, citable steps so the agent follows your policy, not its guesses.
• Use a reconciliation sub-agent to keep per-entity work isolated and reviewable.
• Validate against a known historical period first — never debut on a live close.

Step 1: Lay out the plugin directory

Everything starts with structure. A Cowork plugin is a folder Claude can read, and a sensible layout keeps skills, connectors, and sub-agents separated so each can evolve independently.

finance-close/
  plugin.json            # manifest: name, version, what it bundles
  skills/
    month-end-close/
      SKILL.md           # the close procedure
      materiality.md     # variance thresholds, cited
  connectors/
    warehouse.json       # MCP server config (read-only role)
    erp.json             # MCP server config (approval-gated writes)
  agents/
    reconciler.md        # sub-agent: conservative, cites every number

The manifest ties it together. Keep it minimal — name the bundle and point at its parts. The agent discovers the rest by reading the folder.

Step 2: Wire a read-only warehouse connector

The first capability is data access, and the safest first tool is read-only SQL against your warehouse. Define the MCP server with a role that physically cannot mutate data, then expose a tightly typed tool. Below is a connector config plus the tool the agent will call.

// connectors/warehouse.json
{
  "name": "warehouse",
  "command": "npx",
  "args": ["-y", "@yourco/mcp-snowflake"],
  "env": { "SNOWFLAKE_ROLE": "FINANCE_READONLY" },
  "tools": [{
    "name": "get_trial_balance",
    "description": "Trial balance rows for an entity and period.",
    "input_schema": {
      "type": "object",
      "properties": {
        "entity_id": { "type": "string" },
        "period":    { "type": "string", "pattern": "^[0-9]{4}-[0-9]{2}$" }
      },
      "required": ["entity_id", "period"]
    }
  }]
}

The FINANCE_READONLY role is doing real work: even if the agent is somehow coaxed into trying to write, the database rejects it. Defense lives in the system, not just the prompt.

Step 3: Encode the close procedure as a skill

Now teach the agent your process. The skill's SKILL.md is plain instructions Claude loads only when a close is in play. Write it as you'd write a runbook for a new analyst — numbered, specific, and pointing at your own thresholds file.

# Month-End Close

When asked to close a period:
1. For each entity in scope, call get_trial_balance(entity, period).
2. Compare each account to the prior period.
3. Flag any variance above the threshold in materiality.md.
4. For flagged accounts, draft a one-line explanation and cite the rows.
5. Produce a close summary table; do NOT post entries without approval.

Notice step 5 — the skill itself reinforces the guardrail. The agent reads this only during close work, so it never bloats unrelated requests. The flow from request to reviewed output looks like this.

flowchart TD
  A["'Close May for US & UK'"] --> B["Load month-end-close skill"]
  B --> C["Spawn reconciler sub-agent per entity"]
  C --> D["get_trial_balance via warehouse connector"]
  D --> E{"Variance > threshold?"}
  E -->|No| F["Mark account clean"]
  E -->|Yes| G["Draft explanation + cite rows"]
  F --> H["Merge into close summary"]
  G --> H
  H --> I["Return summary + transcript for review"]

Step 4: Define the reconciliation sub-agent

The reconciler.md sub-agent is where you set tone and rigor. Configure it to be conservative, to refuse to invent figures, and to cite the exact rows behind every number. Because each entity gets its own sub-agent instance, the UK close runs in a context window untouched by the US close, which is what keeps multi-entity runs from blurring together.

Decision	Choose this	Why
Data access	Read-only role first	Eliminates accidental writes
Procedure	Skill, not system prompt	Loads only when relevant
Multi-entity	One sub-agent each	Context isolation
Writes (journals)	Approval gate	Human stays in the loop

Common pitfalls

• Testing on a live period. Always backtest on a closed month where you know every number. If the agent reproduces a known-good close, you've earned trust.
• Letting the model write SQL freely. Prefer a parameterized tool like get_trial_balance over an open run_sql; it narrows the surface and makes outputs predictable.
• Skipping the materiality file. Without cited thresholds, the agent will improvise what counts as a material variance. Pin it down.
• No human gate on journal entries. Drafting entries is fine; posting them without sign-off is not. Keep writes behind explicit approval.
• Forgetting to persist the transcript. The run log is your evidence; export it with the summary.

Ship it in 7 steps

1. Create the finance-close directory with the layout above.
2. Stand up the warehouse MCP connector with a read-only role and the get_trial_balance tool.
3. Write SKILL.md and materiality.md with your real procedure and thresholds.
4. Define the reconciler sub-agent with conservative, cite-everything instructions.
5. Install the plugin in Cowork and run it against a closed historical month.
6. Diff the agent's summary against the actual filed close and fix any gaps in the skill.
7. Only then add the ERP write connector behind an approval gate and pilot on the next live close.

Frequently asked questions

Do I need to write code, or just configuration?

Mostly configuration plus prose. The connectors may be off-the-shelf MCP servers; the skill and sub-agent are written in plain instructions. The engineering effort is in schemas, roles, and testing — not building a model.

How long does a realistic first build take?

For a single warehouse connector and a one-entity close, an engineer can have a working backtest in a day or two. Multi-entity and ERP writes add time mostly in access control and review, not in the agent itself.

What if the agent gets a number wrong during backtesting?

That's the point of backtesting — trace the wrong figure through the transcript, find whether it was a bad tool result or a skill-step gap, and tighten that step. Wrong answers in a known period are cheap; wrong answers in a live close are not.

Bringing agentic AI to your phone lines

The same pattern you just built — connectors, skills, and isolated sub-agents — is exactly how CallSphere runs agentic voice and chat: assistants that answer every call, fetch records mid-conversation, and book work 24/7. See it in action at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.