Connecting Tenkr to Third-Party APIs

At some point you will want Tenkr to talk to a service it does not already know about. Maybe your team uses a project management tool, a CRM, a monitoring dashboard, or an internal API. Tenkr can integrate with any of these, but how you integrate matters more than whether you can.

Tenkr has a clear hierarchy for integrating with external services, ranked from best to worst. This article walks through each option and a real integration end to end.

The Integration Hierarchy

There are three ways Tenkr can interact with an external API. They are not interchangeable. Each has different tradeoffs in reliability, debuggability, and maintenance cost.

1. Native REST API (best). Write a Python script that calls the API directly. Tenkr runs the script via its shell. You control authentication, error handling, retry logic, and response parsing. When something breaks, you read the script and fix it. There is no middleware, no protocol translation, no black box.

2. CLI tool (good). If someone has already built a command-line tool for the service — and the tool is well-maintained — Tenkr can wrap CLI commands directly. This gives you the simplicity of shell commands with the benefit of someone else handling the API details. The downside is you are now dependent on the CLI tool's release cycle and its opinion about which API features to expose.

3. MCP server (last resort). MCP (Model Context Protocol) adds a server process between Tenkr and the API. Tenkr sends structured tool calls to the MCP server, which translates them into API requests. This adds complexity at every layer: an extra process to manage, a protocol to debug, server-specific configuration, and error messages that may obscure the actual API failure. Use MCP when no native API or CLI exists, or when a well-maintained MCP server already handles the integration you need.

The hierarchy is not about capability — all three can do the same things. It is about operational cost. When an integration breaks at 2 AM, you want the fewest layers between you and the problem.

When to Use Each Approach

Native REST: The API has good docs, you need full control, the integration is critical. Avoid when a CLI already tracks API changes for you.
CLI tool: A mature CLI exists (e.g., gh, aws) and covers your use cases. Avoid when the CLI is abandoned or missing key features.
MCP server: No API docs, no CLI, but an MCP server exists and is maintained. Avoid when you can write 50 lines of Python that does the same thing.

Building a Native REST Integration

This is the most common path and the one you should default to. Here is what the process looks like end to end.

Step 1: Understand the API

Before asking Tenkr to write anything, you need three pieces of information:

Authentication method. API key in a header? OAuth token? Basic auth? Check the service's developer docs.
Endpoints you need. Most integrations start with one or two endpoints. Do not try to wrap the entire API.
Response format. JSON is standard. If the API returns XML or something unusual, note that.

You do not need to read the entire API reference. Find the one endpoint that does what you need, understand its parameters, and move on.

Connect Tenkr to any API your team uses.

Step 2: Ask Tenkr to Write the Script

Tell Tenkr what you want. Be specific about the endpoint, the authentication, and what you want to do with the response. For example:

Write a Python script that calls the Acme API to fetch all open support tickets assigned to my team. The API base URL is https://api.acme.com/v2. Authentication is via API key in the X-Api-Key header. Store the API key in an environment variable called ACME_API_KEY.

Tenkr will produce a script that handles authentication, makes the request, parses the response, and outputs the results. A typical integration script is under 30 lines of Python.

Step 3: Test and Iterate

Run the script. If the API returns an error, paste the error back to Tenkr and ask it to fix the script. Common issues:

401 Unauthorized. The API key is wrong or the environment variable is not set.
404 Not Found. The endpoint path is wrong. Check the API docs.
Rate limiting. The API returns 429. Add retry logic with exponential backoff.

Once the script works, save it to your project's scripts directory. Now Tenkr can call it in any session.

Step 4: Build a Skill Around It

If you find yourself asking Tenkr to run this script frequently, wrap it in a skill. The skill adds structure: it defines when to use the script, how to interpret the output, and what to do with the results.

Using a CLI Tool

Some services have excellent CLI tools that handle authentication, pagination, error handling, and output formatting. When one exists, use it instead of writing a script from scratch.

Tenkr wraps CLI commands naturally. You do not need any special configuration — just tell Tenkr what the CLI can do and how to call it. If the CLI has good --help output, Tenkr can even discover commands on its own.

CLI tools sometimes lag behind the API. A feature ships in the API but the CLI does not support it yet. In that case, fall back to native REST for that specific feature and keep the CLI for everything else. Mixing approaches is fine — use the right tool for each endpoint.

Using MCP as a Last Resort

MCP servers sit between Tenkr and an external service. Tenkr calls MCP tools, and the server translates those calls into API requests.

When MCP Makes Sense

The service has no public API documentation, but someone built an MCP server for it.
The MCP server handles complex authentication flows (OAuth with refresh tokens, SAML) that would be painful to implement in a script.
You need real-time bidirectional communication, not just request-response.

The MCP Tax

MCP adds operational cost at every layer:

Debugging. When a call fails, is it the MCP server, the underlying API, or the protocol translation? You have three places to look instead of one.
Configuration. Each server has its own authentication, environment variables, and runtime requirements.
Fragility. MCP servers are maintained by third parties. If the maintainer stops updating, you inherit the maintenance.
Performance. Every call goes through an extra process. For high-frequency operations, the overhead adds up.

None of these are dealbreakers. But they are real costs that native REST and CLI integrations do not have.

The Decision Tree

When you want to integrate a new service, work through this:

Does the service have API documentation? If yes, write a native Python script. Stop here.
Does a mature CLI tool exist? If yes, and it covers your use cases, use the CLI. Stop here.
Does a maintained MCP server exist? If yes, install and configure it. Stop here.
None of the above? Write a native Python script against whatever API access you can find.

Most integrations are one or two Python scripts. They take 15 minutes to write, they are easy to debug, and they do not depend on anything outside your project. Start there, and only reach for CLI or MCP when the simpler option genuinely does not work.

What This Unlocks

Once Tenkr can call an external API, the integration compounds. A script that fetches support tickets today becomes a skill that triages tickets tomorrow, which becomes part of a daily routine that surfaces critical issues before your standup. The initial script is small. The leverage is not.

The key insight is that Tenkr does not need a special integration framework. It needs a script it can run, output it can parse, and context about when to use it. Everything else — the skill, the agent, the routine — builds on top of that foundation.