Which integrations are available for this server?

Allows ChatGPT to interact with the AgroClimate platform to manage company connections, retrieve device and sensor data, weather information, harvest and export details, and more.

How do I use agroclimate-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agroclimate-mcp Show me today's weather data for my main farm" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agroclimate-mcp

by cogrowersqa

Overview Schema Related Servers Score Discussions

TypeScript

Remote

AgroClimate MCP Server

Servidor MCP (Model Context Protocol) que conecta ChatGPT/Claude con la API REST de AgroClimate, permitiendo a los usuarios consultar información de su empresa mediante lenguaje natural.

Requisitos

Node.js 20+ LTS
npm 10+

Related MCP server: dssat-mcp

Instalación

# Instalar dependencias
npm install

# Copiar variables de entorno
cp .env.example .env

# Generar ENCRYPTION_KEY
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

# Editar .env con la URL de la API y la ENCRYPTION_KEY generada

Compilar

npm run build

Ejecutar (desarrollo)

npm run dev

Configuración en ChatGPT / Claude Desktop

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "agroclimate": {
      "command": "node",
      "args": ["C:/Repositorio/MCP/AgroClimate/dist/index.js"],
      "env": {
        "API_BASE_URL": "https://api.agroclimate.cl",
        "ENCRYPTION_KEY": "<tu-key-64-hex>",
        "LOG_LEVEL": "info",
        "LOG_DIR": "./logs",
        "NODE_ENV": "production",
        "SESSION_TTL_HOURS": "24",
        "SESSION_CLEANUP_INTERVAL_MIN": "60",
        "CACHE_TTL_SECONDS": "300",
        "CACHE_MAX_ENTRIES": "1000",
        "API_TIMEOUT_MS": "30000"
      }
    }
  }
}

ChatGPT (Custom GPT con Actions)

Para ChatGPT, se requiere un wrapper HTTP. Consulta la documentación de OpenAI para configurar un GPT Action que apunte al servidor MCP.

Herramientas Disponibles

Tool	Descripción
`connect_company`	Conecta una empresa validando la API Key
`disconnect_company`	Desconecta la empresa y cierra sesión
`get_devices`	Lista dispositivos/sensores
`get_sensor_history`	Historial de lecturas
`get_weather`	Información climática
`get_bins_today`	Bins recolectados hoy
`get_harvest`	Información de cosecha
`get_exports`	Datos de exportación
`get_dispatches`	Despachos pendientes/completados
`company_info`	Info de empresa conectada
`healthcheck`	Estado del servidor

Agregar Nuevos Tools

Crear src/tools/nuevo_tool.ts siguiendo la estructura existente
Importar y agregar al array en src/tools/index.ts
Compilar: npm run build

No se requiere modificar el servidor principal ni ningún otro módulo.

Arquitectura

Consultar ARCHITECTURE.md para el documento completo de arquitectura.

Available Tools

7 tools

company_infoA

Muestra la información de la empresa actualmente conectada. Incluye nombre, usuario, rol, cantidad de dispositivos y estado de la sesión.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

The description implies read-only behavior with 'Muestra' (shows), and no annotations are provided. It could explicitly state no side effects, but the description is clear and consistent for a read-only info tool.

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

Conciseness5/5

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

A single, well-structured sentence communicates purpose and content efficiently. Every word adds value, and the description is front-loaded with the action and resource.

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

Completeness5/5

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

Given the tool has no parameters and no output schema, the description completely covers what the tool returns by listing the fields. It provides sufficient context for an agent to use the tool correctly.

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

Parameters4/5

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

The tool has zero parameters, and schema description coverage is 100%, so the baseline is 4. The description adds no parameter info, but none is needed due to the lack of parameters.

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

Purpose5/5

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

The description clearly states the tool shows company information of the currently connected company, specifying the included fields (name, user, role, devices, session status). This specific verb+resource combination differentiates it from sibling tools like get_devices or disconnect_company.

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

Usage Guidelines4/5

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

The description implies use when company info is needed and indicates the context of a current connection. However, it does not explicitly mention when not to use it or provide comparisons to sibling tools, though the tool's simplicity makes such guidance less critical.

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

connect_companyA

Conecta una empresa al sistema usando su API Key. Normalmente la empresa se conecta automáticamente al iniciar la sesión (via OAuth). Solo usar esta herramienta si se necesita reconectar o cambiar de empresa.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No	La API Key del cliente obtenida desde el Portal Web (sección 'API para Clientes'). Si el usuario no la ha proporcionado, dejar vacío para abrir el formulario de autenticación.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description lacks details on side effects, authentication requirements beyond the API key, success/failure behaviors, or timeouts. It only states the basic action.

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

Conciseness5/5

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

The description is extremely concise—two sentences—with no redundant information. It front-loads the action and then provides usage context.

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?

For a simple tool with one parameter and no output schema, the description covers the essential use case but omits return values and error handling. Given the lack of an output schema, this is a notable gap.

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

Parameters5/5

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

The description adds significant value beyond the schema: it explains where to obtain the API key and how to handle a missing key (leave empty to open authentication form). This fully compensates for the schema's simple description.

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 verb 'Conecta' and the resource 'empresa', and explains the use of API Key. It differentiates from normal OAuth flow but does not explicitly differentiate from sibling tools.

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

Usage Guidelines4/5

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

The description provides clear guidance on when to use the tool ('solo si es necesario reconectar o cambiar de empresa'), but does not specify when not to use it or mention alternatives.

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

disconnect_companyA

Desconecta la empresa actual y cierra sesión completamente. Revoca tokens, limpia caché y fuerza re-autenticación. Usar cuando el usuario quiere cerrar sesión o cambiar de empresa.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that it revokes tokens, clears cache, and forces re-authentication, giving good behavioral insight beyond the tool name.

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

Conciseness5/5

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

Two sentences: first describes actions, second gives usage scenario. No wasted words, front-loaded with key information.

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

Completeness5/5

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

Given no parameters, no output schema, and no annotations, the description fully covers the tool's behavior and usage context. It is complete and sufficient.

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

Parameters4/5

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

No parameters in schema; baseline for 0 params is 4. Description does not need to add parameter info and focuses on tool behavior, which is appropriate.

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

Purpose5/5

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

Description clearly states the verb 'desconecta' and 'cierra sesión', the resource 'empresa actual', and the specific actions (revoca tokens, limpia caché, fuerza re-autenticación). It distinguishes from siblings like 'connect_company' and 'company_info'.

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

Usage Guidelines4/5

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

Explicitly says 'Usar cuando el usuario quiere cerrar sesión o cambiar de empresa', providing clear when-to-use context. It does not list when not to use, but the context is sufficient.

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

get_devicesA

Obtiene el estado actual de dispositivos y sensores de la empresa conectada. Incluye análisis automático: resumen general, rankings (temperatura, humedad, horas frío, porciones frío), estado de conexión, extremos geográficos y detalle por dispositivo.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided. The description only lists output content but does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects.

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

Conciseness5/5

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

The description is a single sentence with a clear list, front-loading the core purpose. Every word adds value without redundancy.

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 zero parameters and no output schema, the description adequately covers what is returned. However, it omits prerequisite conditions (e.g., company must be connected) and error scenarios.

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

Parameters4/5

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

No parameters exist, so baseline 4 applies. No additional semantic value needed.

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

Purpose5/5

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

The description clearly states it retrieves current device and sensor status, listing specific analyses included. It is distinct from sibling tools that handle connection management, history, or weather.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies it is for current status, but does not exclude cases or mention prerequisites like company connection.

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

get_sensor_historyA

Obtiene estadísticas de temperatura, humedad, horas frío y porciones frío de un dispositivo. Siempre consulta los últimos 30 días de la API y filtra según el período solicitado. Permite análisis en bloques horarios configurables (por ejemplo 3, 4, 5 o 24 horas). El LLM debe interpretar la pregunta del usuario y pasar fecha_desde y/o fecha_hasta para filtrar. Si no se pasan fechas, muestra estadísticas de las últimas 24 horas por defecto.

ParametersJSON Schema

Name	Required	Description
`dispositivo`	Yes	Código del dispositivo a consultar (codigo_dispositivo). Obligatorio.
`fecha_desde`	No	Fecha/hora de inicio del filtro en formato ISO 8601 (YYYY-MM-DD o YYYY-MM-DD HH:mm). También acepta: hoy, ayer, esta semana, semana pasada, este mes, mes pasado, este año, año pasado. Opcional. Si no se indica, se asumen las últimas 24 horas.
`fecha_hasta`	No	Fecha/hora de fin del filtro en formato ISO 8601 (YYYY-MM-DD o YYYY-MM-DD HH:mm). También acepta: hoy, ayer, esta semana, semana pasada, este mes, mes pasado, este año, año pasado. Opcional. Si no se indica, se asume el momento actual.
`intervalo_horas`	No	Tamaño de bloque para análisis de porciones frío (en horas). Ejemplos: 3, 4, 5, 24. Opcional. Por defecto: 3.

TDQS

A4.4/5.0

Behavior4/5

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

Describes internal behavior: always fetches last 30 days then filters, and defaults to last 24 hours. No annotations exist, so description carries full burden; read-only nature could be more explicit.

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

Conciseness5/5

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

Three sentences, front-loaded with purpose, then behavior and guidance. Every sentence contributes meaning without redundancy.

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

Completeness4/5

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

Covers purpose, behavior, and parameter usage well. Missing output format details, but no output schema exists; still adequate for agent to understand tool's function.

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

Parameters4/5

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

Schema covers all parameters (100% coverage). Description adds value by explaining default interval (3 hours), date defaults, and that LLM should interpret user input for date parameters.

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

Purpose5/5

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

Description clearly states verb 'Obtiene' (gets) and resource 'estadísticas de temperatura, humedad, horas frío y porciones frío de un dispositivo', distinguishing it from sibling tools like get_devices and get_weather.

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

Usage Guidelines4/5

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

Specifies that the LLM should interpret user queries to pass dates, and describes default behavior when no dates provided. However, does not explicitly state when not to use this tool vs alternatives.

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

get_weatherA

Obtiene información climática actual y pronóstico para la ubicación de la empresa. Incluye temperatura, humedad, viento y pronóstico.

ParametersJSON Schema

Name	Required	Description	Default
`ubicacion`	No	Ubicación específica a consultar (opcional, usa la ubicación principal si no se indica).

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or error handling. It only lists data fields, which is minimal for a tool without annotation support.

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

Conciseness5/5

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

Single sentence, front-loaded with purpose and contents. No wasted words, efficient for an AI agent to parse quickly.

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?

Tool is simple (1 optional param, no output schema). Description covers purpose and contained data but lacks details on forecast period, units, or response format. Adequate but not thorough.

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 describes the 'ubicacion' parameter well (optional, defaults to main location). With 100% schema coverage, the description adds no extra parameter info beyond purpose.

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

Purpose5/5

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

The description clearly states the verb ('obtiene') and resource ('información climática actual y pronóstico para la ubicación de la empresa'), specifying the data included. No sibling tools overlap with weather, so purpose is distinct.

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

Usage Guidelines4/5

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

The description implies usage context (company's location, optional specific location) but does not explicitly state when to use vs alternatives. However, no sibling provides weather data, so guidance is sufficient.

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

healthcheckA

Verifica el estado del servidor MCP, la conectividad con la API y las estadísticas de sesión y caché.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions the tool checks status, connectivity, and stats, implying a read-only operation. However, it does not disclose latency, error behavior, or what happens if components are unavailable. Adequate but lacks depth.

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

Conciseness5/5

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

A single, concise sentence that delivers the essential information without any superfluous content. Every word earns its place.

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

Completeness4/5

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

Given no parameters and no output schema, the description covers the primary aspects: what is checked (server, API, session, cache). However, it could include what the tool returns or behaves in failure cases, making it slightly incomplete.

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

Parameters4/5

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

The input schema has no parameters, so schema coverage is 100%. The description need not add parameter information. Baseline 4 applies as no additional meaning is required.

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

Purpose5/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: verifying server status, API connectivity, and session/cache statistics. It uses a specific verb 'Verifica' and identifies the resources, effectively distinguishing it from sibling tools like get_devices or connect_company.

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 no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusion criteria, leaving the agent to infer usage.

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. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jul 28, 2026
- First observedcompany_info
- First observedconnect_company
- First observeddisconnect_company
- First observedget_devices
- First observedget_sensor_history
- First observedget_weather
- First observedhealthcheck

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: device status, session management, sensor history, weather, company info, and health check. No overlap or ambiguity.

Naming Consistency4/5

Most tools follow a verb_noun pattern (get_devices, get_sensor_history), but company_info and healthcheck omit the verb. Still clear and readable.

Tool Count5/5

7 tools is well-scoped for an agroclimate monitoring server, covering essential functionality without bloat.

Completeness4/5

Covers device status, sensor history, weather, company management, and health checks. Missing update/delete for devices or historical weather, but core workflows are supported.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgenticBIOAuth
io.github.AgenticBIHQ
Connect Claude, Cursor, or ChatGPT to your business data. Ask questions, get answers.
Search RAG Systems Databases
2
ContextfloOAuth
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1
Cayra Decision IntelligenceOAuth
io.cayra
Ask questions in plain language, get answers from your business database. No SQL required.
1
Vibe BI MCPOAuth
ai.vibe-bi
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
Databases Search
2

Related MCP Servers

Rasdaman MCP Server
Databases Research & Data
fastmcp-me
A
license
A
quality
D
maintenance
Enables natural language interaction with rasdaman databases, allowing users to list coverages, describe datacubes, and execute WCPS queries.
Updated 7 months ago (2026-02-10 21:19 UTC)
5
MIT
dssat-mcp
Research & Data AI & Machine Learning
BeomseokForWork
A
license
Not graded
quality
D
maintenance
Enables natural language interaction with the DSSAT crop model for simulation, calibration, and sensitivity analysis through LLM agents.
Updated 6 months ago (2026-02-28 12:48 UTC)
1
MIT
mydata
Finance Fitness Tracking Databases
bibekg
A
license
Not graded
quality
D
maintenance
Enables querying personal data synced from services like Lunch Money and Strava using SQL via Claude.
Updated 7 months ago (2026-02-01 02:37 UTC)
15
1
MIT
mcp-marketing-analytics
Marketing Search
christophertanenso
F
license
A
quality
D
maintenance
Enables natural language querying of Google Analytics 4, Google Search Console, Meta Ads, and Google Ads data through Claude.
Updated 6 months ago (2026-02-26 07:04 UTC)
23
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cogrowersqa/agroclimate-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

AgroClimate MCP Server

Requisitos

Instalación

Compilar

Ejecutar (desarrollo)

Configuración en ChatGPT / Claude Desktop

Claude Desktop (claude_desktop_config.json)

ChatGPT (Custom GPT con Actions)

Herramientas Disponibles

Agregar Nuevos Tools

Arquitectura

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)