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:
Note: Either
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:
* Required when
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:
HTTP Configuration:
Config Object Fields:
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:
Important Differences from Main Schema:
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.
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.
Note: These hints are advisory and do not enforce any behavior. They help AI agents understand the tool’s characteristics for better decision-making.
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
Body Configuration
Thebody field defines the request body:
Retry Configuration
Theretries field configures retry behavior:
Examples
GET Request with Query ParametersCLI Execution
Execute command-line tools and scripts. Type:"cli"
Fields
Flag Configuration
Each flag in theflags object has:
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
When
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
The text is processed with the full templating engine (basic placeholders, loops, and conditionals).
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
Examples
API Key in HeaderBearer Token Authentication
Pass a bearer token in theAuthorization header.
Type: "bearer"
Fields
Example
Basic Authentication
Use HTTP Basic Authentication with username and password. Type:"basic"
Fields
Example
OAuth2 Authentication
Authenticate using OAuth2 client credentials flow. Type:"oauth2"
Fields
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.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)
