de en es ja ko ru zh

Jentic

Name: Jentic
Author: jentic

Official

by jentic

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Complemento MCP de Jentic

insignia de herrería

¿Por qué utilizar Jentic MCP?

Jentic MCP permite a los desarrolladores descubrir e integrar rápidamente API y flujos de trabajo externos, sin necesidad de escribir ni mantener código específico de la API. Al aprovechar el protocolo MCP y el entorno de ejecución de Jentic, los desarrolladores pueden:

Busque API y flujos de trabajo por capacidad, no por proveedor o implementación.
Genere instantáneamente ejemplos de código de integración que sean independientes de los detalles específicos de la API.
Evite el código repetitivo y reduzca el mantenimiento confiando en una integración declarativa y estandarizada.
Concéntrese en desarrollar funciones, mientras Jentic MCP maneja la complejidad de la interacción de la API.

Related MCP server: agent-zone-mcp

Herramientas API

El complemento Jentic MCP proporciona las siguientes herramientas:

search_apis : busca API en el directorio de Jentic que coincidan con necesidades de funcionalidad específicas
load_execution_info : Recupera especificaciones detalladas de las API y operaciones del directorio de Jentic. Esto incluye la información de autenticación que podría necesitar proporcionar en la configuración de mcpServers.jentic.env .
execute : ejecutar una API específica o una operación de flujo de trabajo.

Empezando

El método recomendado es ejecutar el servidor directamente desde el repositorio de GitHub con uvx . Primero deberá instalar uv con:

brew install uv o pip install uv

Obtenga su UUID de Jentic

Para usar el SDK de Jentic, primero debe obtener un UUID de Jentic. La forma más sencilla es usar la CLI de Jentic. Opcionalmente, puede incluir una dirección de correo electrónico para obtener límites de velocidad más altos y acceso anticipado a nuevas funciones.

pip install jentic
jentic register --email '<your_email>'

Esto imprimirá su UUID y un comando de exportación para configurarlo en su entorno:

export JENTIC_UUID=<your-jentic-uuid>

Establezca el UUID de Jentic en la configuración de su cliente MCP como se muestra a continuación.

La ubicación del archivo de configuración depende del cliente que utilice y de su sistema operativo. Algunos ejemplos comunes:

Windsurf : ~/.codeium/windsurf/mcp_config.json
Escritorio de Claude : ~/Library/Application Support/Claude/claude_desktop_config.json
Código de Claude : ~/.claude.json
Cursor : ~/cursor/.mcp.json

Para otros clientes, consulte la documentación de su cliente para saber cómo agregar servidores MCP.

{
    "mcpServers": {
        "jentic": {
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp",
                "mcp"
            ],
            "env": {
                "JENTIC_UUID": "<your-jentic-uuid>"
            }
        }
    }
}

Nota: Después de guardar el archivo de configuración, es posible que deba reiniciar la aplicación cliente (Windsurf, Claude Desktop) para que los cambios surtan efecto.

Uso de la herramienta MCP

Una vez que el servidor MCP esté en funcionamiento, puede usar fácilmente las herramientas MCP en su agente LLM para descubrir y ejecutar API y flujos de trabajo.

search_apis : busca API en el directorio de Jentic que coincidan con necesidades de funcionalidad específicas
load_execution_info : Recupera especificaciones detalladas de las API y operaciones del directorio de Jentic. Esto incluye la información de autenticación que podría necesitar proporcionar en la configuración de mcpServers.jentic.env .
execute : ejecutar una API específica o una operación de flujo de trabajo.

Variables de entorno

Al usar una API que requiere autenticación, la herramienta load_execution_info describirá las variables de entorno necesarias. Puede configurar las variables de entorno mediante la línea de comandos en Windsurf, aunque en algunos clientes como Claude Desktop, deberá agregarlas a la configuración de MCP:

{
    "mcpServers": {
        "jentic": {
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp",
                "mcp"
            ],
            "env": {
                "DISCORD_BOTTOKEN=": "YOUR BOT TOKEN"
            }
        }
    }
}

Alternativa (utilizando la ruta local para el desarrollo):

Use esto si está desarrollando activamente el complemento MCP localmente. Reemplace /path/to/your/project/mcp con la ruta absoluta al directorio de su proyecto.

{
    "mcpServers": {
        "jentic": { 
            "command": "uvx",
            "args": [
                "--from",
                "/path/to/your/project/mcp",
                "mcp" 
            ]
        }
    }
}

Opcional: agregue una variable de entorno JENTIC_API_URL a su archivo mcp_config.json para apuntar a una API de Jentic específica (funciona con ambos métodos):

{
    "mcpServers": {
        "jentic": {
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp",
                "mcp"
            ],
            "env": {
                "JENTIC_API_URL": "https://your-jentic-api.url/"
            }
        }
    }
}

Una vez configurado, reinicie Windsurf y las herramientas Jentic MCP estarán disponibles.

Puede seguir los registros generados por el servidor MCP que se ejecuta localmente ejecutando:

tail /path/to/mcp/jentic_ark2_mcp.log

Instalación

Instalación mediante herrería

Para instalar el complemento Jentic para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install @jentic/jentic-tools --client claude

Instalación manual

Asegúrese de tener pdm instalado ( pipx install pdm ).

Para instalar el paquete y sus dependencias para el desarrollo:

# From the project root directory (e.g., /Users/kc/c/sdk/mcp)
pdm install -G dev

Ejecución del servidor MCP

El complemento Jentic MCP está diseñado para ejecutarse utilizando uvx , que maneja la configuración y ejecución del entorno.

Modo predeterminado (Stdio)

Ejecute el complemento MCP directamente usando uvx , especificando el directorio del proyecto como fuente usando --from y el script mcp :

Desde la ruta local (desarrollo):

# Use --from with the project directory and specify the 'mcp' script
uvx --from /path/to/your/project/mcp mcp

# Or, if running from within the project directory:
uvx --from . mcp

Desde el repositorio remoto (recomendado para uso general):

uvx --from \
  git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp \
  mcp

Esto utiliza automáticamente el comando serve --transport stdio predeterminado definido en la devolución de llamada del script mcp .

Modo HTTP

Para ejecutar el servidor en modo HTTP (por ejemplo, para probar con claude-cli ):

Desde la ruta local (desarrollo):

# Default HTTP (port 8010)
uvx --from /path/to/your/project/mcp mcp serve --transport http

# With custom port
uvx --from /path/to/your/project/mcp mcp serve --transport http --port 8080

# With custom host
uvx --from /path/to/your/project/mcp mcp serve --transport http --host 0.0.0.0 --port 8080

Desde el repositorio remoto (recomendado):

uvx --from \
  git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp \
  mcp serve --transport http --port 8080

Ejecución desde un repositorio Git remoto

También puedes ejecutar el servidor MCP directamente desde una URL de repositorio Git sin clonarlo localmente usando uvx --from :

# Example from a specific branch and subdirectory
uvx --from \
  git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp

# Explanation:
# - git+https://... .git : The repository URL
# - @main   : The branch, tag, or commit hash
# - #subdirectory=mcp     : The folder within the repo containing the pyproject.toml

Este comando obtiene la versión especificada, instala sus dependencias en un entorno temporal y ejecuta el comando predeterminado (que es serve --transport stdio ).

Puede agregar otros argumentos como --log-level DEBUG o --mock después del fragmento de URL:

uvx --from \
  git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp \
  --log-level DEBUG --mock

Para ejecutar en modo HTTP desde una fuente remota:

uvx --from \
  git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp \
  serve --transport http --port 8080

Otras opciones

Explotación florestal

# Set logging level (applies to default stdio or explicit serve)
uvx --from /path/to/your/project/mcp mcp --log-level DEBUG
uvx --from /path/to/your/project/mcp mcp serve --transport http --log-level DEBUG

# Log to file (applies to default stdio or explicit serve)
uvx --from /path/to/your/project/mcp mcp --log-file jentic_mcp.log
uvx --from /path/to/your/project/mcp mcp serve --transport http --log-file jentic_mcp.log

Modo simulado

Habilite el modo simulado para el desarrollo sin conectarse al Centro de conocimiento de la API de Jentic real:

# Mock mode with default stdio
uvx --from /path/to/your/project/mcp mcp --mock

# Mock mode with explicit HTTP
uvx --from /path/to/your/project/mcp mcp serve --transport http --mock

Variables de entorno

Proporcione variables de entorno utilizando un archivo .env :

# Env file with default stdio
uvx --from /path/to/your/project/mcp mcp --env-file .env

# Env file with explicit HTTP
uvx --from /path/to/your/project/mcp mcp serve --transport http --env-file .env

Usando con Claude

El complemento MCP se puede utilizar con Claude u otros LLM que admitan la especificación MCP:

Ejecutar desde el repositorio remoto (recomendado):

# Run the server in HTTP mode first
uvx --from \
  git+https://github.com/jentic/jentic-tools.git@main#subdirectory=mcp \
  mcp serve --transport http --port 8000

# Then connect claude-cli
claude-cli --mcp http://localhost:8000

Ejecutar desde la ruta local (desarrollo):

# Run the server in HTTP mode first
uvx --from /path/to/your/project/mcp mcp serve --transport http --port 8000

# Then connect claude-cli
claude-cli --mcp http://localhost:8000

Desarrollo

Consulte CLAUDE.md para obtener instrucciones de desarrollo detalladas.

Estructura del paquete

src/mcp/ : Paquete principal de MCP
- transport/ : Implementaciones de transporte (HTTP, stdio)
- mock/ : Proveedores de datos simulados para el desarrollo
- tools.py : Definiciones de herramientas
- handlers.py : Controladores de solicitudes
- main.py : puntos de entrada de la CLI
- adapters/ : Implementaciones de adaptadores
- core/ : Funcionalidad principal
tests/ : Conjunto de pruebas

Pruebas

# Ensure dev dependencies are installed: pdm install -G dev
pdm run test

Pelusa y formato

Utiliza ruff , black , isort , mypy a través de scripts pdm.

# Run all linters/formatters
pdm run lint

# Run only ruff
pdm run linter

Licencia

Propietario - Jentic

Available Tools

3 tools

executeC

Perform the chosen action for the user using the provided details (if any are needed).

ParametersJSON Schema

Name	Required	Description
`execution_type`	Yes	Specify whether to execute an 'operation' or a 'workflow'.
`inputs`	Yes	The input parameters required by the operation or workflow.
`uuid`	Yes	The UUID of the operation or workflow to execute.

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'perform the chosen action' which implies a write/mutation operation, but doesn't disclose critical behavioral traits: whether this is synchronous/asynchronous, what permissions are required, whether it's idempotent, what happens on failure, or what the response contains. For a tool that appears to execute potentially complex operations/workflows, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point without unnecessary words. However, this conciseness comes at the cost of being under-specified for a tool with three required parameters and no annotations - it could benefit from one more clarifying sentence about what gets executed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 required parameters (including a nested object), no annotations, and no output schema, the description is inadequate. It doesn't explain what types of actions can be executed, what the expected outcomes are, or provide any error handling context. The agent would struggle to use this tool effectively without trial and error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond the generic 'using the provided details' - it doesn't clarify the relationship between execution_type, uuid, and inputs, or provide examples of valid input objects. Baseline 3 is appropriate when the schema does all the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Perform the chosen action for the user using the provided details' is tautological - it essentially restates the tool name 'execute' without specifying what kind of actions or resources are involved. While it mentions 'chosen action' and 'provided details', it doesn't clarify whether this executes operations, workflows, scripts, or other entities, nor does it distinguish this from sibling tools like 'load_execution_info' or 'search_apis'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance - it mentions 'chosen action' and 'provided details' but gives no explicit when-to-use criteria, no prerequisites, and no comparison to alternatives like 'load_execution_info' (which presumably loads execution information rather than performing execution) or 'search_apis'. The agent must infer usage from the parameter schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

load_execution_infoC

Get more details about a specific action (like what information it needs from the user) before confirming you want to run it. Usually used if the action requires specific inputs. Coding Agents: To provide tools to an LLM that you have selected at runtime, use this tool to retrieve the necessary information and save it to 'jentic.json' at the root of your project.

ParametersJSON Schema

Name	Required	Description	Default
`operation_uuids`	Yes	The UUIDs of the operations to include in the configuration files.
`workflow_uuids`	Yes	The UUIDs of the workflows to include in the configuration files.

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions retrieving information and saving to a file, but doesn't disclose critical traits like whether this is a read-only operation, if it modifies state, authentication needs, rate limits, or error handling. The description adds some context but leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise but not optimally structured. The first sentence clearly states the purpose, but the second sentence adds implementation details for coding agents that may not apply to all users. The information is somewhat front-loaded but could be more focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should provide more complete context. It mentions retrieving details and saving to a file, but doesn't explain what format the details take, what 'jentic.json' contains, or what happens if parameters are invalid. For a tool with 2 required parameters and mutation implications, this is inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add meaningful semantic context beyond what the schema provides about operation_uuids and workflow_uuids. It mentions 'configuration files' but doesn't clarify how parameters relate to this output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'Get more details about a specific action' which indicates its purpose, but it's vague about what 'details' means and doesn't clearly differentiate from sibling tools like 'execute' or 'search_apis'. It mentions saving to 'jentic.json' which adds specificity but confuses the core purpose with implementation details for coding agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some guidance ('Usually used if the action requires specific inputs') but lacks explicit when-to-use vs. alternatives. It doesn't clarify when to choose this over 'execute' or 'search_apis', and the coding agent note is situational rather than general usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_apisA

Search for available actions or information based on what the user wants to do (e.g., 'find Discord servers', 'send a message'). Use this first to understand what's possible.

ParametersJSON Schema

Name	Required	Description
`capability_description`	Yes	Natural language description of the action needed (e.g., 'send emails', 'weather forecasting', 'natural language processing')
`keywords`	No	Optional list of specific keywords to help narrow down the search
`max_results`	No	Maximum number of actions to return

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool searches for actions or information but lacks details on behavioral traits such as response format, error handling, rate limits, or authentication needs. For a search tool with zero annotation coverage, this is a significant gap, though it does imply it returns results (e.g., 'to return' in the schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage guidelines. Every sentence earns its place by providing essential information without redundancy. It could be slightly more concise by integrating examples more seamlessly, but overall it's well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers purpose and usage well but lacks behavioral details like return format or error handling. Without annotations or an output schema, the description should do more to compensate, making it minimally viable but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any additional meaning beyond what the schema provides, such as explaining how 'capability_description' interacts with 'keywords' or detailing search algorithms. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for available actions or information based on what the user wants to do.' It provides a specific verb ('search') and resource ('available actions or information'), with examples like 'find Discord servers' and 'send a message' to illustrate usage. However, it doesn't explicitly distinguish this from sibling tools like 'execute' or 'load_execution_info', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Use this first to understand what's possible.' This clearly indicates it should be employed as an initial step to discover capabilities before invoking other tools, effectively differentiating it from siblings like 'execute' (which likely performs actions) and 'load_execution_info' (which might retrieve details).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0May 9, 2025
- First observedexecute
- First observedload_execution_info
- First observedsearch_apis

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

C2.9/5.0

Scored 2026-04-18 10:10 across 3 tools

Disambiguation4/5

The tools have distinct primary purposes: 'search_apis' discovers available actions, 'load_execution_info' retrieves details for a specific action, and 'execute' performs the action. There is minor potential overlap between 'load_execution_info' and 'execute' in handling action details, but the descriptions clarify their sequential workflow roles.

Naming Consistency3/5

The naming is mixed: 'search_apis' and 'load_execution_info' use snake_case with descriptive verbs, while 'execute' is a single verb without a noun. This inconsistency in structure (two tools follow a verb_noun pattern, one does not) reduces predictability, though the names remain readable.

Tool Count4/5

With 3 tools, the count is reasonable for a server focused on action discovery and execution. It feels slightly thin but covers core workflows (search, detail retrieval, execution), avoiding bloat. A few more tools might enhance completeness, but this is a solid minimal set.

Completeness3/5

The tool set covers a basic workflow (search, load info, execute) for action-based operations, but there are notable gaps. For example, there's no tool for managing or listing previously executed actions, error handling, or status checks, which could limit agent effectiveness in more complex scenarios.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

KodyOAuth
io.github.kentcdodds
Your agents' cloud. MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2775
inflowOAuth
ai.inflowpay.app
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Agent Orchestration Autonomous Agents Payments & Billing
26
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221
Security Mcp A
io.github.varvararatta
MCP server for Security
Security Penetration Testing
2

Related MCP Servers

Huntress-MCP-Server
Security Monitoring Developer Tools
DynamicEndpoints
A
license
Not graded
quality
Not graded
maintenance
MCP server for Huntress API integration
Updated a year ago (2025-07-16 05:30 UTC)
1
MIT
agent-zone-mcp
Agent Orchestration Developer Tools RAG Systems
statherm
A
license
Not graded
quality
C
maintenance
MCP server for Agent Zone — vendor-neutral infrastructure knowledge, K8s validation, and execution templates for AI agents. 200+ articles, 10 tools, no API key required.
Updated 8 months ago (2026-02-26 06:36 UTC)
17 npm
MIT
inflow-mcpofficial
Finance Payments & Billing
inflowpayai
A
license
Not graded
quality
D
maintenance
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Updated 6 months ago (2026-04-15 04:58 UTC)
6
MIT
Grupr MCP Serverofficial
Communication Agent Orchestration
grupr-ai
A
license
A
quality
B
maintenance
MCP server to interact with Grupr agents, enabling polling new messages, posting replies, and managing event webhooks.
Updated 6 days ago (2026-10-07 20:04 UTC)
4
13 npm
MIT

Complemento MCP de Jentic

¿Por qué utilizar Jentic MCP?

Herramientas API

Empezando

Obtenga su UUID de Jentic

Uso de la herramienta MCP

Variables de entorno

Instalación

Instalación mediante herrería

Instalación manual

Ejecución del servidor MCP

Modo predeterminado (Stdio)

Modo HTTP

Ejecución desde un repositorio Git remoto

Otras opciones

Explotación florestal

Modo simulado

Variables de entorno

Usando con Claude

Desarrollo

Estructura del paquete

Pruebas

Pelusa y formato

Licencia

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Huntress-MCP-Server

agent-zone-mcp

inflow-mcpofficial

Grupr MCP Serverofficial