OpenCode is usually described as a coding agent. It reads your repo, writes code, runs tests, opens PRs. That's the main loop.

But underneath that loop is a capable agent runtime—tool execution, file I/O, multi-step reasoning, long context. None of that is specific to writing code. If you give OpenCode a research prompt instead of a coding task, it works. If you connect it to your company's internal tools instead of a codebase, it works.

People looking for a general-purpose AI agent that can connect to their company's systems often overlook tools like OpenCode because the marketing says "coding." This post explains why it's worth a look for non-code tasks too.

Why a coding agent works for non-code tasks

Coding agents are built to handle complexity. They break down vague instructions into steps, use tools to gather information, iterate when something doesn't work, and produce structured output. Those are the same capabilities you need for research, writing, data analysis, or orchestrating workflows across services.

OpenCode specifically gives you:

Tool execution – The agent can call HTTP APIs, query databases, search documentation, and interact with any service that has an endpoint
File I/O – It can read, write, and transform files. Useful for generating reports, processing data, or producing documents
Multi-step reasoning – It doesn't just answer a question. It plans an approach, gathers information across multiple sources, and synthesizes a result
Long context – It can hold a lot of information in context across a session, making it useful for tasks that require correlating data from multiple places

The only difference between a "coding agent" and a "general-purpose agent" is what tools you give it and what you ask it to do.

Connecting tools with MCP

OpenCode supports MCP (Model Context Protocol)—a standard for connecting AI agents to external tools and data sources. An MCP server exposes a set of tools that the agent can discover and call.

This matters because it means you can connect OpenCode to anything your company already has. A few examples of what people build MCP servers for:

Internal wikis and docs – Confluence, Notion, Google Docs. The agent searches your knowledge base to answer questions or write documents grounded in existing content
CRM and customer data – Salesforce, HubSpot, your own database. Ask the agent to pull account summaries, find patterns in support tickets, or draft customer communications
Project management – Linear, Jira, Asana. The agent reads tickets, understands priorities, and can create or update issues as part of a workflow
Communication – Slack, email, Discord. The agent can draft messages, summarize threads, or post updates to channels
Data warehouses – BigQuery, Snowflake, Postgres. Give the agent read-only access and let it run queries to answer business questions

The agent doesn't need to know about your systems in advance. It discovers what tools are available through the MCP protocol and decides when to use them based on the task.

Writing your own tools

If your company has internal services with HTTP APIs, you can wrap them as tools that OpenCode can call. The simplest approach is an MCP server that proxies requests to your internal endpoints.

A basic MCP server for an internal knowledge base might look like:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "internal-docs", version: "1.0.0" });

server.tool(
  "search_docs",
  "Search internal documentation. Returns matching articles with title, url, and excerpt.",
  { query: z.string().describe("Search query"), limit: z.number().optional() },
  async ({ query, limit = 10 }) => {
    const response = await fetch(
      `https://wiki.yourcompany.com/api/search?q=${encodeURIComponent(query)}&limit=${limit}`,
      { headers: { Authorization: `Bearer ${process.env.WIKI_TOKEN}` } }
    );
    const results = await response.json();
    return { content: [{ type: "text", text: JSON.stringify(results, null, 2) }] };
  }
);

server.tool(
  "get_article",
  "Fetch the full content of a specific documentation article by ID.",
  { articleId: z.string().describe("The article ID from search results") },
  async ({ articleId }) => {
    const response = await fetch(
      `https://wiki.yourcompany.com/api/articles/${articleId}`,
      { headers: { Authorization: `Bearer ${process.env.WIKI_TOKEN}` } }
    );
    const article = await response.json();
    return { content: [{ type: "text", text: article.body }] };
  }
);

Register this in your OpenCode config and the agent can search and read your internal docs during any session. Same pattern works for any HTTP service—wrap the endpoints, describe what they return, and let the agent figure out when to call them.

Use cases beyond code

Once the agent has access to your company's tools and knowledge, the range of tasks it can handle goes well beyond writing code. A few patterns we've seen:

Research and analysis – "Pull our last 3 months of support tickets, identify the top 5 recurring themes, and write a summary with recommendations." The agent queries your ticketing system, reads the data, and produces a structured report
Content drafting – "Write a blog post about our new feature based on the PRD in Notion and the design specs in Figma." The agent pulls context from multiple sources and drafts content grounded in your actual plans
Internal Q&A – "How does our billing system handle refunds?" Instead of searching the wiki yourself, let the agent search, read the relevant articles, and give you a clear answer with sources
Report generation – "Generate a weekly engineering metrics report from our deployment logs and Linear data." The agent queries multiple systems and produces a formatted summary
Workflow orchestration – "When a P0 incident is filed, pull the related service's recent deploys, check error rates in Datadog, and post a preliminary RCA to Slack." Multi-step, multi-system workflows that would normally require custom scripting

The common pattern: you're asking the agent to gather context from your systems, reason about it, and produce some output. That's not coding—it's just work.

Running this via CodeCloud

Running OpenCode locally with MCP servers works, but it requires keeping the servers running, managing authentication, and setting up the config on every machine. If you want this as a service—triggered from automation, available to your whole team, no local setup—CodeCloud handles the infrastructure.

The key difference: instead of writing MCP servers and managing config, you pass tools directly in the API request. CodeCloud converts them to native OpenCode tools automatically. You define what each tool does, where it points, and what auth it needs—the rest is handled.

curl -X POST https://codecloud.dev/api/v1/agents \
  -H "Authorization: Bearer cc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "blank_workspace": true,
    "prompt": "Research our top customer complaints from the last month. Search support tickets, check the product roadmap for related planned fixes, and write a summary with recommendations for the product team.",
    "tools": [
      {
        "name": "search_tickets",
        "description": "Search support tickets. Returns ticket title, customer, priority, tags, and description.",
        "parameters": {
          "type": "object",
          "properties": {
            "query": { "type": "string", "description": "Search query" },
            "since": { "type": "string", "description": "ISO date, return tickets after this date" },
            "priority": { "type": "string", "enum": ["critical", "high", "medium", "low"] }
          },
          "required": ["query"]
        },
        "endpoint": {
          "url": "https://support.yourcompany.com/api/tickets/search",
          "method": "GET",
          "headers": { "Authorization": "Bearer support-api-token" }
        }
      },
      {
        "name": "get_roadmap_items",
        "description": "Fetch items from the product roadmap. Returns title, status, target quarter, and description.",
        "parameters": {
          "type": "object",
          "properties": {
            "status": { "type": "string", "enum": ["planned", "in_progress", "shipped"] },
            "search": { "type": "string", "description": "Search by keyword" }
          }
        },
        "endpoint": {
          "url": "https://internal.yourcompany.com/api/roadmap",
          "method": "GET",
          "headers": { "Authorization": "Bearer roadmap-token" }
        }
      }
    ]
  }'

No MCP server to build or host. No config files. Just describe the endpoints and pass the auth. The agent gets the tools as native capabilities and uses them as needed.

This is especially useful for teams that want to give non-engineers access to agent-powered workflows. A product manager doesn't need to run a local MCP server—they trigger a CodeCloud run from Slack, a webhook, or a simple script, and get the result back.

When to use what

OpenCode + MCP locally – Best for individual use, exploration, and tasks where you want interactive control. You manage the MCP servers and config
CodeCloud with API tools – Best for team workflows, automations, and integrations. No local setup, tools defined per-request, runs in the cloud
CodeCloud + blank_workspace – Best for non-code tasks. No repo needed, just tools and a prompt. Use this for research, reports, data processing, and orchestration

All three use the same underlying agent. The difference is where it runs and how you give it tools.

Getting started

If you're already using OpenCode for coding, try giving it a non-code task. Set up an MCP server that connects to one of your internal systems—your wiki, your CRM, your project tracker—and ask the agent to answer a question or generate a report.

If you want to skip the MCP setup and run it as a service, try CodeCloud with blank_workspace: true and a couple of tools pointed at your internal APIs. Start simple—one or two tools, a straightforward prompt. You'll quickly see that the agent handles non-code tasks just as well as coding ones.

For full API details, see the documentation. Questions or feedback? Reach out at support@codecloud.dev.