Bring your own models and private tools to Yodu

The model and the tools are different layers.

The model provides reasoning and generation. Tools let an AI employee read or change something outside the conversation. A company should be able to choose both without rebuilding its entire operating system.

Yodu supports workspace-level model providers and remote custom MCP servers for that reason.

Quick answer

Bring your own model access by configuring a supported provider at the workspace level, then choose models by employee and job. Add private tools through a remote HTTPS MCP server, verify its health, and switch it on for one employee first. Keep credentials encrypted, scoped, revocable, and out of prompts.

Bring the model access you already use

Open Organization settings → Yodu.

The current options include:

• OpenAI API access
• Anthropic API access
• supported Claude subscription access
• OpenRouter API access

Provider secrets are encrypted and not displayed after saving. Configure the provider once for the workspace, then select an available model for an employee.

That design follows the same boundary described in OpenAI's API key safety guidance: keep keys out of client-side code and source control, restrict access, monitor usage, and rotate credentials when needed.

Choose a model by job

Do not assume every role needs the most expensive model.

| Work | What to optimize | | ------------------- | -------------------------------------- | | Deep research | Reasoning, source use, long context | | Support triage | Latency, consistency, clear escalation | | Content drafting | Voice adherence and revision quality | | Engineering | Code reasoning and test discipline | | Scheduled summaries | Predictable cost and stable formatting |

Measure accepted output and rework, not model prestige.

Rotate provider access safely

When rotating a key or token:

1. pause dependent schedules
2. save the replacement value
3. test one employee message
4. run one representative task
5. resume recurring work after the test passes

Never paste the provider secret into chat, memory, files, or employee configuration markdown.

When to use MCP

MCP, the Model Context Protocol, defines a standard way for an AI application to discover and call external tools.

Yodu has three distinct MCP surfaces: Platform MCP lets an external client operate Yodu, employee MCP usage lets an employee call an external server, and the custom MCP catalog stores the workspace's approved server definitions. This article covers the employee/custom-server direction. For the external-client direction, use the Platform MCP quickstart.

Use a custom MCP server when:

• the system is private to your company
• the vendor is not in the app catalog
• the workflow needs a specialist tool surface
• you want to expose a narrow set of business actions

Examples:

• read product usage for a customer
• search approved contracts
• list open invoices
• prepare a CRM note
• retrieve internal catalog data

Add the server

Open Tool access → Custom MCP.

Add:

• a recognizable name
• the remote HTTPS endpoint
• an optional authorization header value

Yodu stores the authorization value as a workspace secret and checks the server's protocol health. Use the re-test control whenever the endpoint or credential changes.

Healthy does not mean safe

A green health state proves connectivity and protocol compatibility. It does not prove that every exposed tool has the right scope.

Design narrow tools:

Good:

• get_customer_usage
• search_contracts
• draft_crm_note

Risky:

• run_sql
• admin_action
• do_everything

The smaller the tool surface, the easier it is to understand the grant and review the result.

Authorization deserves first-class design

The official MCP authorization specification is based on OAuth 2.1 and protected-resource metadata for remote protected servers. When a server supports that flow, use scoped, revocable authorization rather than a broad long-lived token.

Yodu's current custom-server form also supports an optional authorization header for servers that use a direct credential. Treat it as sensitive workspace access.

Roll out one employee at a time

1. Add the server.
2. Confirm healthy state.
3. Test one read-only tool.
4. Switch the server on for one employee and off for the rest.
5. Let the approval gate hold any consequential action.
6. Assign one task with known input.
7. Review the output and source data.
8. Expand access only after the narrow workflow succeeds.

A combined scorecard

| Metric | Why it matters | | ------------------------------- | ------------------------------------------------------- | | Accepted output by model | Shows whether model choice helps the job | | Rework rate | Reveals instruction or model mismatch | | Cost per accepted output | Connects provider spend to useful work | | MCP health checks passed | Confirms basic reachability | | Tool actions reviewed | Shows whether the private capability is being inspected | | Tools switched off after review | Reveals access cleanup and learning |

The principle

Bring-your-own access should increase choice without weakening policy.

The workspace chooses the providers. The job chooses the model. The company connects the server. The employee receives only the capability it needs. The human remains responsible for the boundary.

Configure the next layer

Follow the model access guide, review the tool-connection model, then use the MCP server security checklist before granting a private capability to an employee. To operate Yodu itself from another AI client, compare the REST and MCP paths on the developer platform.