Overview
MCI (Model Context Interface) uses a schema to define tools that AI agents can execute. The schema can be written in either JSON or YAML format - both are fully supported and produce identical results. Each tool specifies:- What it does (metadata and description)
- What inputs it accepts (JSON Schema)
- How to execute it (execution configuration)
1.0
Supported File Formats:
- JSON (
.json) - YAML (
.yaml,.yml)
Top-Level Schema Structure
The root MCI context file has these main fields:| Field | Type | Required | Description |
|---|---|---|---|
schemaVersion | string | Required | MCI schema version (e.g., "1.0") |
metadata | object | Optional | Descriptive metadata about the tool collection |
tools | array | Optional* | Array of tool definitions |
toolsets | array | Optional* | Array of toolset references to load from library |
mcp_servers | object | Optional | MCP servers to register and cache (see MCP Servers) |
libraryDir | string | Optional | Directory to find toolset files (default: "./mci") |
enableAnyPaths | boolean | Optional | Allow any file path (default: false) |
directoryAllowList | array | Optional | Additional allowed directories (default: []) |
tools, toolsets, or mcp_servers (or any combination) must be provided.
Toolsets
toolsets (array, optional)
- Array of toolset definitions that reference tool collections in the library directory
- Each toolset can optionally apply schema-level filtering to control which tools are loaded
- Allows organizing tools into reusable, modular collections
libraryDir (string, default: "./mci")
- Directory path where toolset files are located, relative to the main schema file
- Can be customized to use a different directory structure
Toolset Object
Each toolset object supports these fields:| Field | Type | Required | Description |
|---|---|---|---|
name | string | Required | Name of toolset file/directory in libraryDir |
filter | string | Optional | Filter type: "only", "except", "tags", or "withoutTags" |
filterValue | string | Required* | Comma-separated list of tool names or tags |
filter is specified
Toolset Name Resolution:
- First checks for a directory:
{libraryDir}/{name}/- If found, loads all
.mci.jsonfiles in the directory
- If found, loads all
- Then checks for direct file:
{libraryDir}/{name} - Then checks with extension:
{libraryDir}/{name}.mci.json - Also supports
.mci.yamland.mci.ymlextensions
only: Include only tools with specified namesexcept: Exclude tools with specified namestags: Include only tools with at least one matching tagwithoutTags: Exclude tools with any matching tag
Security Fields
enableAnyPaths (boolean, default: false)
- When
true, disables all path validation for file and CLI execution - When
false(default), restricts access to schema directory and allowed directories - Can be overridden per-tool
- Use with caution - enables access to any file on the system
directoryAllowList (array of strings, default: [])
- List of additional directories to allow for file/CLI access
- Can be absolute paths (e.g.,
/home/user/data) or relative to schema directory (e.g.,./configs) - Schema directory is always allowed by default
- Can be overridden per-tool
MCP Servers
Themcp_servers field enables integration with Model Context Protocol servers.
mcp_servers (object, optional)
- Object mapping server names to MCP server configurations
- Allows integration with Model Context Protocol (MCP) servers
- Tools from MCP servers are automatically cached in
{libraryDir}/mcp/directory - Each server configuration can include filtering and expiration settings
- Supports both STDIO (local command-based) and HTTP (web-based) servers
MCP Server Configuration
Each server in themcp_servers object has a unique name as the key and a configuration object with these fields:
STDIO Configuration:
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
command | string | Yes | - | Command to execute (e.g., "npx", "uvx") |
args | array of strings | No | [] | Arguments to pass to the command |
env | object | No | {} | Environment variables for the server process |
config | object | No | - | Optional caching and filtering configuration |
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
type | string | Yes | - | Must be "http" |
url | string | Yes | - | Server URL endpoint |
headers | object | No | {} | HTTP headers (e.g., for authentication) |
config | object | No | - | Optional caching and filtering configuration |
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
expDays | integer | No | 30 | Number of days until cached toolset expires |
filter | string | No | - | Filter type: "only", "except", "tags", "withoutTags" |
filterValue | string | No | - | Comma-separated list of tool names or tags (required if filter) |
MCP Server Examples
STDIO Server with Filtering:- First Load: When the schema is loaded, MCI connects to each MCP server and fetches all available tools
- Caching: Tools are saved as standard MCI toolset files in
{libraryDir}/mcp/{serverName}.mci.json - Subsequent Loads: Cached toolsets are used instead of connecting to the server (much faster)
- Expiration: When cache expires (based on
expDays), tools are re-fetched from the server - Filtering: Optional filters are applied when tools are registered
- Templating: Server configurations support
{{env.VAR}}templating for credentials
Example (JSON)
Example with Toolsets (JSON)
Example (YAML)
Toolset Schema Files
Toolset files are MCI schema files stored in the library directory (default:./mci). They provide a way to organize and reuse tool collections across different main schemas.
Toolset File Structure
Toolset files have a simplified structure compared to main schemas:| Field | Type | Required | Description |
|---|---|---|---|
schemaVersion | string | Required | MCI schema version (must match main schema) |
metadata | object | Optional | Descriptive metadata about the toolset |
tools | array | Required | Array of tool definitions |
toolsfield is required in toolset files (optional in main schema)- Cannot contain
toolsets,libraryDir,enableAnyPaths, ordirectoryAllowListfields - These are purely tool definition files, not configuration files
Example Toolset File (JSON)
File:./mci/weather.mci.json
Toolset Directory Structure
You can organize related toolsets in subdirectories:- Only tools are merged from toolset files; metadata is not merged
- All files in a directory must use the same schema version
- Schema version mismatch will raise an error to ensure compatibility
- Metadata in toolset files is for demonstration and documentation purposes only
- It helps credit toolset authors and provides human-friendly descriptions
- Metadata is never merged into the main schema from toolset files }
Example (YAML)
Tool Definition
Each tool in thetools array represents a single executable operation.
| Field | Type | Required | Description |
|---|---|---|---|
name | string | Required | Unique identifier for the tool |
disabled | boolean | Optional | If true, the tool is ignored (default: false) |
annotations | object | Optional | Metadata and behavioral hints (see Annotations) |
description | string | Optional | Description of what the tool does |
inputSchema | object | Optional | JSON Schema describing expected inputs |
execution | object | Required | Execution configuration (see Execution Types) |
enableAnyPaths | boolean | Optional | Override schema-level path restriction (default: false) |
directoryAllowList | array | Optional | Override schema-level allowed directories (default: []) |
tags | array | Optional | Array of string tags for filtering (default: []) |
Tags
tags (array of strings, default: [])
- List of tags for categorizing and filtering tools
- Tags are case-sensitive and matched exactly as provided
- Used with
tags()andwithoutTags()filter methods in MCIClient and ToolManager - Tools can have zero or more tags
- Common tag examples:
"api","database","internal","external","deprecated"
Disabled Tools
disabled (boolean, default: false)
- When
true, the tool is excluded from all listing, filtering, and lookup operations - Disabled tools cannot be executed and behave as if they do not exist
- Useful for temporarily deactivating tools without removing them from the schema
Annotations
Theannotations object provides optional metadata and behavioral hints about the tool. All fields are optional.
| Field | Type | Description |
|---|---|---|
title | string | Human-readable title for the tool |
readOnlyHint | boolean | If true, the tool does not modify its environment |
destructiveHint | boolean | If true, the tool may perform destructive updates |
idempotentHint | boolean | If true, repeated calls with same args have no additional effect |
openWorldHint | boolean | If true, the tool interacts with external entities |
Security Fields (Per-Tool)
enableAnyPaths (boolean, default: false)
- Overrides schema-level setting for this specific tool
- When
true, disables path validation for this tool - Takes precedence over schema-level
enableAnyPaths
directoryAllowList (array of strings, default: [])
- Overrides schema-level setting for this specific tool
- List of additional directories allowed for this tool only
- Takes precedence over schema-level
directoryAllowList - Can be absolute or relative paths
Example (JSON)
Example with Disabled Tool (JSON)
Example with Security Overrides (JSON)
Example with Directory Allow List (YAML)
Example with All Annotation Hints (YAML)
Execution Types
MCI supports four execution types:http, cli, file, and text. The type field in the execution object determines which executor is used.
HTTP Execution
Execute HTTP requests to external APIs. Type:"http"
Fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
type | string | Required | - | Must be "http" |
method | string | Optional | "GET" | HTTP method: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS |
url | string | Required | - | Target URL (supports templating) |
headers | object | Optional | - | HTTP headers as key-value pairs (supports templating) |
auth | object | Optional | - | Authentication configuration (see Authentication) |
params | object | Optional | - | Query parameters as key-value pairs (supports templating) |
body | object | Optional | - | Request body configuration |
timeout_ms | integer | Optional | 30000 | Request timeout in milliseconds (must be ≥ 0) |
retries | object | Optional | - | Retry configuration |
Body Configuration
Thebody field defines the request body:
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Required | Body type: "json", "form", or "raw" |
content | object/string | Required | Body content (object for json/form, string for raw) |
Retry Configuration
Theretries field configures retry behavior:
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
attempts | integer | Optional | 1 | Number of retry attempts (must be ≥ 1) |
backoff_ms | integer | Optional | 500 | Backoff delay in milliseconds (must be ≥ 0) |
Examples
GET Request with Query ParametersCLI Execution
Execute command-line tools and scripts. Type:"cli"
Fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
type | string | Required | - | Must be "cli" |
command | string | Required | - | Command to execute |
args | array | Optional | - | Fixed positional arguments |
flags | object | Optional | - | Dynamic flags mapped from properties |
cwd | string | Optional | - | Working directory (supports templating) |
timeout_ms | integer | Optional | 30000 | Execution timeout in milliseconds (must be ≥ 0) |
Flag Configuration
Each flag in theflags object has:
| Field | Type | Required | Description |
|---|---|---|---|
from | string | Required | Property path (e.g., "props.ignore_case") |
type | string | Required | Flag type: "boolean" or "value" |
boolean: Flag is included only if the property is truthy (e.g.,-i)value: Flag is included with the property value (e.g.,--file=myfile.txt)
Examples
Basic CLI CommandFile Execution
Read and parse file contents with optional templating. Type:"file"
Fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
type | string | Required | - | Must be "file" |
path | string | Required | - | File path (supports templating) |
enableTemplating | boolean | Optional | true | Whether to process templates in file content |
enableTemplating is true, the file contents are processed with the full templating engine (basic placeholders, loops, and conditionals).
Examples
Load Template FileText Execution
Return templated text directly. Type:"text"
Fields
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Required | Must be "text" |
text | string | Required | Text template (supports templating) |
Examples
Simple MessageAuthentication
HTTP execution supports four authentication types: API Key, Bearer Token, Basic Auth, and OAuth2.API Key Authentication
Pass an API key in headers or query parameters. Type:"apiKey"
Fields
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Required | Must be "apiKey" |
in | string | Required | Where to send the key: "header" or "query" |
name | string | Required | Header/query parameter name |
value | string | Required | API key value (supports templating, typically {{env.API_KEY}}) |
Examples
API Key in HeaderBearer Token Authentication
Pass a bearer token in theAuthorization header.
Type: "bearer"
Fields
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Required | Must be "bearer" |
token | string | Required | Bearer token (supports templating, typically {{env.BEARER_TOKEN}}) |
Example
Basic Authentication
Use HTTP Basic Authentication with username and password. Type:"basic"
Fields
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Required | Must be "basic" |
username | string | Required | Username (supports templating, typically {{env.USERNAME}}) |
password | string | Required | Password (supports templating, typically {{env.PASSWORD}}) |
Example
OAuth2 Authentication
Authenticate using OAuth2 client credentials flow. Type:"oauth2"
Fields
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Required | Must be "oauth2" |
flow | string | Required | OAuth2 flow type (e.g., "clientCredentials") |
tokenUrl | string | Required | Token endpoint URL |
clientId | string | Required | OAuth2 client ID (supports templating) |
clientSecret | string | Required | OAuth2 client secret (supports templating) |
scopes | array | Optional | Array of scope strings |
Example
Templating Syntax
The MCI templating engine supports placeholder substitution, loops, and conditional blocks. Templating is available in:- Execution configurations (URLs, headers, params, body, etc.)
- File contents (when
enableTemplating: true) - Text execution
Context Structure
The templating engine has access to three contexts:props: Properties passed toexecute()methodenv: Environment variables passed to the adapterinput: Alias forprops(for backward compatibility)
Basic Placeholders
Replace placeholders with values from the context. Syntax:{{path.to.value}}
Examples
For Loops
Iterate a fixed number of times using a range. Syntax:@for(variable in range(start, end))...@endfor
variable: Loop variable namestart: Starting value (inclusive)end: Ending value (exclusive)
Example
Template:Foreach Loops
Iterate over arrays or objects from the context. Syntax:@foreach(variable in path.to.collection)...@endforeach
variable: Loop variable namepath.to.collection: Path to an array or object in the context
Array Example
Context:Object Example
Context:Conditional Blocks
Execute code conditionally based on values in the context. Syntax:Supported Conditions
- Truthy check:
@if(path.to.value) - Equality:
@if(path.to.value == "expected") - Inequality:
@if(path.to.value != "unexpected") - Greater than:
@if(path.to.value > 10) - Less than:
@if(path.to.value < 100)
Examples
Simple Conditional:Execution Result Format
All tool executions return a consistent result format.| Field | Type | Description |
|---|---|---|
isError | boolean | Whether an error occurred during execution |
content | any | Result content (if successful) |
error | string | Error message (if isError: true) |
metadata | object | Optional metadata (e.g., HTTP status code, CLI exit code) |
Metadata Fields by Execution Type
Different execution types include specific metadata: HTTP Execution Metadata:status_code(integer): HTTP status coderesponse_time_ms(integer): Response time in milliseconds
exit_code(integer): Command exit code (0 for success, non-zero for failure)stdout_bytes(integer): Size of stdout in bytesstderr_bytes(integer): Size of stderr in bytesstderr(string): Standard error output (if any)stdout(string): Standard output (only included in error results)
