Canonical keys are syllago’s cross-provider equivalents — the normalized names for fields, behaviors, and conventions that different AI coding tools express in their own ways. Each key below links to a detail page showing how every provider implements (or does not implement) that concept.
See format conversion for how keys translate between providers.
| Key | Description |
|---|
agent_scopes | Where agent definitions can live and the priority ordering when definitions exist at multiple levels |
definition_format | What format agent definitions use |
invocation_patterns | How agents are triggered |
model_selection | Whether per-agent model overrides are supported, allowing different agents to use different AI models |
per_agent_mcp | Whether agents can have their own MCP server configuration, scoping which external tools each agent can access |
subagent_spawning | Whether agents can spawn, delegate to, or resume other agents |
tool_restrictions | Whether agents can be restricted to specific tools via allowlists, denylists, tool categories, or per-tool configuration maps |
| Key | Description |
|---|
argument_substitution | How user-provided arguments are injected into command templates |
builtin_commands | Whether the provider ships default/built-in commands alongside user-defined custom commands |
| Key | Description |
|---|
async_execution | Whether hooks can run asynchronously without blocking the agent’s execution loop |
context_injection | Whether hooks can inject messages, system prompts, or conversation context into the agent’s active session |
decision_control | Which decision actions hooks can take on the triggering action |
handler_types | What kinds of executors hooks support beyond shell commands |
hook_scopes | Where hooks can be configured and the precedence model when multiple scopes define hooks for the same event |
input_modification | Whether hooks can modify tool input arguments before the tool executes |
json_io_protocol | Whether hooks communicate with the host via structured JSON on stdin/stdout rather than plain text or exit codes alone |
matcher_patterns | Whether hooks can filter which tools or events they respond to using name matching, regex patterns, or structured criteria |
permission_control | Whether hooks can make or influence permission decisions determining whether a tool is available for invocation |
| Key | Description |
|---|
auto_approve | Whether specific MCP tools or entire servers can be configured for automatic approval without per-invocation user confirmation |
enterprise_management | Whether the provider supports organization-level MCP configuration management, including managed server lists, allowlists, and enterprise registries |
env_var_expansion | Whether MCP server configuration supports environment variable expansion |
marketplace | Whether the provider offers an in-IDE MCP server discovery and installation experience |
oauth_support | Whether the provider supports OAuth 2 |
resource_referencing | Whether MCP resources (not just tools) can be accessed, typically via @-mention syntax or similar referencing mechanisms |
tool_filtering | Which per-server tool filtering mechanisms the provider supports |
transport_types | Which MCP transport protocols the provider supports |
| Key | Description |
|---|
activation_mode | How rules decide when to load into context |
auto_memory | Whether the provider auto-generates persistent rules from conversation context |
cross_provider_recognition | Which rule file formats from other providers this provider recognizes |
file_imports | Whether rules can reference or include content from other files |
hierarchical_loading | Whether rules load from multiple directory levels with defined precedence |
| Key | Description |
|---|
canonical_filename | The required or conventional filename for this skill type |
compatibility | Provider compatibility constraints — which AI tool versions or providers this skill is compatible with |
custom_filename | Whether the provider supports custom filenames (beyond the canonical filename convention) |
description | What the skill does |
disable_model_invocation | When true, the AI cannot auto-invoke this skill; only the user can invoke it explicitly |
display_name | Human-readable display name for the skill |
global_scope | Whether the skill can be installed at global/personal scope (applies across all projects for the current user) |
license | SPDX license identifier for the skill content |
metadata_map | Arbitrary key-value metadata attached to the skill |
project_scope | Whether the skill can be installed at project scope (applies to current project only, typically committed to version control) |
shared_scope | Whether the skill can be installed at shared/enterprise scope (applies to all users in an organization or shared environment) |
user_invocable | When false, the skill is hidden from user-facing menus (e |
version | Semantic version string for the skill |