API Integration for RedHat MCP

Integrate third-party APIs with auth, retries, timeouts, and logging.

Security Scan

The skill's instructions match its stated purpose and are low-risk, but metadata and provenance inconsistencies (it claims 'RedHat Dev' yet source/homepage are missing and owner IDs differ) merit caution before installation.

Purpose & Capability

The name, description, and runtime instructions are coherent: this is an instruction-only template for building resilient API clients (timeouts, retries, logging, tests). There are no unexpected required binaries, env vars, or config paths. However the package claims RedHat authorship in SKILL.md/_meta.json while registry metadata shows a different owner ID and the source/homepage are 'unknown'/'none' — a provenance inconsistency worth verifying.

Instruction Scope

SKILL.md limits operations to design/implementation guidance (validate API contract, implement client, normalize errors, add tests) and explicitly warns not to log secrets or run curl|sh. It does not instruct reading arbitrary system files or exfiltrating data. The 'secrets_source' input is intentionally generic — the skill does not itself access secrets but leaves choice of secret store to the implementer, which is acceptable but should be specified before use.

Install Mechanism

This is instruction-only with no install spec and no code files to run. That minimizes code-installation risk (nothing is downloaded or written by the skill itself).

Credentials

No required environment variables or credentials are declared, which aligns with the skill being a template. The optional 'secrets_source' parameter could, in real usage, cause the implementer/agent to access environment variables or a secret manager — that's expected for an integration client but must be constrained and audited by the user (the skill does not define which secret store or credentials to use).

Persistence & Privilege

always: false (default) and the skill does not request persistent/system-wide changes. disable-model-invocation is false (normal) which allows autonomous invocation — not a problem here because the skill is instruction-only and does not hold broad credentials. There is no indication it modifies other skills or system settings.

What to consider before installing

This skill appears to be a sensible template for implementing API clients, but verify provenance before trusting it: the SKILL claims 'RedHat Dev' while registry metadata/owner IDs and source/homepage are missing or inconsistent. Do not provide production secrets to the agent just because the skill mentions a 'secrets_source' — instead: (1) confirm the skill's author/ownership (ask the publisher or review a trusted homepage/repo), (2) run any generated code in a sandbox and review it for unexpected network calls or 'curl | sh' patterns, (3) bind secrets to a vetted secret manager with audit logs and minimal scope, (4) require explicit declarations for which secret store/bindings to use, and (5) if you plan to let an agent generate code from this guidance, review packages/URLs it installs (avoid downloads from unknown hosts). If you cannot verify the provenance, do not run it with sensitive credentials.

SKILL: api-integration

Purpose

Integrate external APIs safely (auth, retries, timeouts, error handling, logging) and expose them via a clean internal interface.

When to Use

• A system must call a third-party REST/WebSocket API.
• You need a reusable client module with predictable behavior.
• You must handle rate limits and transient failures.

Inputs

• api_spec (required, object|string): base URL, endpoints, schemas, rate limits.
• auth_method (optional, enum: none|api_key|oauth|jwt|hmac).
• secrets_source (optional, string): where tokens/keys come from (env/secret manager).
• error_policy (optional, string): retry/backoff rules and non-retryable errors.

Steps

1. Validate API contract and identify required headers/auth.
2. Implement a client module:
   • explicit base URL
   • request timeouts
   • retry with bounded backoff (only for safe/idempotent calls by default)
   • rate limit handling
3. Normalize errors into a stable internal shape.
4. Add logging hooks (request id, endpoint, status, latency; never log secrets).
5. Add tests:
   • mocked responses for determinism
   • at least one failure-path test

Validation

• Secrets are sourced only from configuration (not hardcoded).
• Retry policy is explicit and bounded.
• Errors are deterministic and observable.

Output

• Client module path(s)
• Config/env contract
• Usage example (internal call pattern)

Safety Rules

• Do not paste tokens/keys into code or logs.
• Do not rely on “best effort” network calls without timeouts.
• Avoid curl | sh or ad-hoc install scripts as part of integration.

Example

Integrate “VendorAPI”:

• api_spec: { base_url: "...", endpoints: ["/v1/items"] }
• Output: src/integrations/vendor/client.ts with retries and mocked tests.