Protocolo de Contexto de Modelo (MCP) para la integración con Linear como herramienta de IA. Esta herramienta permite que su IA interactúe con Linear a través del Protocolo de Contexto de Modelo.
Integración lineal completa :
Problemas de búsqueda
Crear nuevos problemas
Problemas de actualización
Añadir comentarios
Actualizar comentarios
Obtener perfiles de usuario
Obtener información del equipo
Related MCP server: Linear MCP Server
Node.js 18 o más reciente
Clave API lineal
Para usar esta aplicación, necesita una clave API de Linear. Estos son los pasos para obtenerla:
Iniciar sesión o crear una cuenta lineal
Visita Linear e inicia sesión en tu cuenta existente o regístrate para crear una nueva cuenta
Acceder a la configuración del espacio de trabajo
Desde la página principal, haga clic en su nombre de usuario en la esquina superior izquierda
Seleccione la opción "Configuración del espacio de trabajo"
Abrir configuración de API
En la columna "Configuración" del lado izquierdo, desplácese hacia abajo hasta encontrar "API".
Haga clic en la opción “API”
Crear una nueva clave API
Ingrese una etiqueta para su clave API (por ejemplo, "Aplicación lineal MCP")
Haga clic en el botón "Crear nueva clave API"
Almacenar la clave API de forma segura
La clave API se mostrará solo una vez
Cópielo y guárdelo en una ubicación segura porque Linear no lo volverá a mostrar.
Nota importante : Linear tiene un límite de 1500 solicitudes de claves API por hora. Asegúrese de que su aplicación respete este límite para evitar errores 429 "Demasiadas solicitudes".
Para obtener información más detallada sobre cómo obtener y utilizar claves de API lineales, puede visitar esta guía en Merge.dev .
Clonar este repositorio:
git clone git@github.com:zalab-inc/mcp-linear-app.git
cd mcp-linear-appInstalar dependencias:
npm installCree un archivo .env en el directorio raíz:
LINEAR_API_KEY=your_linear_api_key_hereConstruir el proyecto:
npm run buildLa carpeta dist ahora está lista para usarse para la configuración en varias plataformas de IA.
Encuentre su archivo de configuración de Cursor MCP:
Windows: C:\Users\<username>\.cursor\mcp.json
macOS: ~/.cursor/mcp.json
Linux: ~/.cursor/mcp.json
Edite el archivo para agregar la configuración del servidor Linear MCP:
{
"mcpServers": {
"linear": {
"command": "<path-to-node>",
"args": [
"<path-to-project>/dist/index.js"
],
"env": {
"LINEAR_API_KEY": "your_linear_api_key_here"
}
}
}
}Reemplace los marcadores de posición:
<path-to-node> : Ruta a su ejecutable Node.js
<path-to-project> : Ruta absoluta al directorio del proyecto de su aplicación lineal MCP
your_linear_api_key_here : Su clave de API lineal
Ejemplo de configuración:
{
"mcpServers": {
"linear": {
"command": "C:\\nvm4w\\nodejs\\node.exe",
"args": [
"H:\\mcp\\linear\\dist\\index.js"
],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxxxxxxxxxxx"
}
}
}
}Guarde el archivo y reinicie Cursor para que los cambios surtan efecto.
Para usar MCP Linear Tools con Claude, debe agregar la configuración al archivo de configuración de Claude. Siga estos pasos:
Abra la configuración de la aplicación de escritorio Claude AI
Vaya a la sección "Desarrollador"
Busque la sección de configuración "Herramientas"
Agregue configuración para MCP lineal de la siguiente manera:
{
"tools": {
"linear": {
"command": "<path-to-node>",
"args": [
"<path-to-project>/dist/index.js"
],
"env": {
"LINEAR_API_KEY": "your_linear_api_key_here"
}
}
}
}Reemplace los marcadores de posición:
<path-to-node> : Ruta a su ejecutable Node.js
<path-to-project> : Ruta absoluta al directorio del proyecto de su aplicación lineal MCP
your_linear_api_key_here : Su clave de API lineal
Ejemplo de configuración:
{
"tools": {
"linear": {
"command": "/usr/local/bin/node",
"args": [
"/Users/username/projects/mcp-linear-app/dist/index.js"
],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxxxxxxxxxxx"
}
}
}
}El principio básico es el mismo para otras plataformas de IA que admiten MCP:
Encuentre el área de configuración para herramientas externas o MCP
Configúrelo para ejecutar Node.js con el archivo dist/index.js de este repositorio
Incluya su LINEAR_API_KEY en la configuración del entorno
Después de la configuración, su IA tendrá acceso a las siguientes herramientas lineales:
search_issues - Busque problemas por palabra clave, estado o prioridad
create_issue - Crea un nuevo problema
get_issue - Obtener detalles del problema
update_issue - Actualizar un problema existente
create_comment - Agregar un comentario a un problema
get_comment - Obtener comentarios de un problema
update_comment - Actualizar o eliminar un comentario
get_profile - Obtener el perfil de usuario lineal actual
get_team_id - Obtener una lista de equipos y sus ID
Si tiene problemas al utilizar esta herramienta, por favor:
Comprueba que tu clave API lineal sea válida y tenga permisos suficientes
Asegúrese de que Node.js esté instalado correctamente
Verifique la configuración de su MCP en su plataforma de IA
Revise los archivos de registro para ver si aparecen mensajes de error
Una vez configuradas las herramientas lineales en tu entorno de IA, puedes empezar a usarlas indicándole a la IA. Aquí tienes algunos ejemplos:
En Cursor, puedes simplemente pedirle a Claude que realice tareas relacionadas con Linear:
Search for high priority issues in our Linear project.Create a new issue in Linear with the title "Improve login page performance" and add it to the backlog.Get the details of the issue LIN-123 from Linear.Add a comment to issue LIN-456 saying "This is fixed in the latest release. Please verify."Update the priority of issue LIN-789 to urgent.A continuación se muestra un ejemplo de flujo de trabajo que muestra cómo puede utilizar estas herramientas:
Encontrar el ID de tu equipo :
What's my Linear team ID?Claude utilizará la herramienta get_team_id para obtener la información de su equipo.
Creando un nuevo problema :
Create a new Linear issue titled "Implement password reset feature" for the Engineering team with a high priority. The description should be "Users need a way to reset their passwords when they forget them."Claude utilizará la herramienta create_issue con los parámetros necesarios.
Buscando problemas :
Find all high priority issues assigned to me that are currently in progress.Claude utilizará la herramienta search_issues con los filtros apropiados.
Actualizando un problema :
Update issue LIN-456 to add the description "This issue has been verified and tested on all browsers."Claude utilizará la herramienta update_issue para modificar el problema.
Añadiendo comentarios :
Add a comment to issue LIN-789 asking "Is this still a priority for this sprint?"Claude usará la herramienta create_comment para agregar el comentario.
Recuperando comentarios :
Show me all the comments on issue LIN-321Claude utilizará la herramienta get_comment para obtener los comentarios.
Estos ejemplos demuestran con qué naturalidad puedes interactuar con Linear a través de tu asistente de IA una vez que las herramientas estén configuradas correctamente.
Este proyecto se ha mejorado recientemente con documentación mejorada y herramientas lineales. Las mejoras incluyen:
README actualizado con instrucciones de instalación y configuración más claras
Documentación mejorada con ejemplos para varias plataformas de IA
Herramientas lineales mejoradas con mejor manejo de errores y formato de respuesta
Se agregó soporte para administrar comentarios (crear, obtener, actualizar, eliminar)
Capacidad de búsqueda mejorada con filtrado por estado y prioridad
Este proyecto está licenciado bajo la licencia MIT.
A tool that creates a comment on an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | The comment to send to the issue | |
| issueId | Yes | The ID of the issue to send a comment to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'creates a comment', implying a write operation, but doesn't address permissions, side effects, rate limits, or response format. This is a significant gap for a mutation tool, making it inadequate for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a write operation with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., permissions, response), usage context, and output information, failing to provide enough guidance for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('comment' and 'issueId'). The description doesn't add any semantic details beyond what the schema provides, such as format constraints or examples, so it meets the baseline of 3 without compensating or enhancing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('creates a comment') and target resource ('on an issue in Linear'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_comment' or 'get_comment', missing an opportunity for sibling differentiation that would warrant a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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's no mention of prerequisites (e.g., needing an existing issue), exclusions, or comparisons to siblings like 'update_comment' for editing or 'get_comment' for reading, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that creates an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | The description of the issue | |
| dueDate | No | The due date of the issue | |
| parentId | No | The ID of the parent issue, used to create a sub-issue | |
| priority | No | The priority of the issue | no_priority |
| status | No | The status of the issue | backlog |
| teamId | Yes | The team ID the issue belongs to | |
| title | Yes | The title of the issue |
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 this is a creation tool, implying mutation, but doesn't mention authentication requirements, rate limits, error conditions, or what happens on success (e.g., returns issue ID). For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns issue object/ID), error handling, or behavioral constraints, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter information beyond what's in the schema, meeting the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('creates') and resource ('an issue in Linear'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'update_issue' or 'search_issues', but the verb 'creates' is specific enough for basic differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'update_issue' or 'search_issues'. It doesn't mention prerequisites (e.g., needing a teamId) or appropriate contexts for creating versus updating issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets comments from an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | The ID of the issue to get comments from |
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 but offers minimal information. It doesn't specify whether this is a read-only operation, what permissions are required, how comments are returned (e.g., format, pagination), or any rate limits. The phrase 'gets comments' implies retrieval but lacks operational details needed for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core function without unnecessary words. However, it could be more front-loaded with critical details like behavioral traits or usage context, which would improve its structure for agent decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns structured comment data. It doesn't explain what the output contains (e.g., comment text, authors, timestamps) or address potential complexities like error handling or authentication needs, leaving significant gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'issueId' clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('gets') and resource ('comments from an issue in Linear'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_issue' or explain what differentiates getting comments from getting the issue itself, 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.
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. With siblings like 'get_issue' and 'search_issues' available, there's no indication whether this tool retrieves all comments for a specific issue or if there are filtering options, nor when one might choose this over other comment-related tools like 'create_comment' or 'update_comment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets an issue from Linear
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | The ID of the issue to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('gets an issue') without disclosing behavioral traits like whether it's a read-only operation, authentication requirements, error handling, or rate limits. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one parameter) and lack of annotations/output schema, the description is incomplete. It doesn't explain what 'gets' entails (e.g., returns issue details), error cases, or how it differs from siblings. For a tool with no structured data support, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'issueId' documented as 'The ID of the issue to retrieve'. The description adds no additional meaning beyond what the schema provides. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'gets an issue from Linear', which provides a basic verb+resource combination. However, it's vague about what 'gets' means (retrieves, fetches, reads) and doesn't distinguish it from sibling tools like 'search_issues' or 'get_comment'. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when to use 'get_issue' versus 'search_issues' for finding issues, or prerequisites like needing an issue ID. There's no explicit or implied context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets the current user's profile from Linear
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool retrieves the current user's profile but doesn't cover aspects like authentication requirements, rate limits, error handling, or the response format. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely involves authentication and returns user data. It doesn't explain what the profile contains, how errors are handled, or any dependencies, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate, as it avoids redundancy while clearly indicating no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('gets') and resource ('current user's profile from Linear'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_team_id' or 'get_issue', which also retrieve data from Linear but target different resources, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, such as authentication, or compare it to sibling tools like 'get_team_id' for team-related data, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets all teams and their IDs from Linear
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying what is retrieved, from where, and the resource type, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but incomplete. It lacks details on behavioral aspects like authentication needs, output format, or error handling. Without annotations or an output schema, the description should provide more context to fully guide an AI agent, but it doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on non-existent parameters, though it could briefly note the lack of inputs for clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'gets all teams and their IDs from Linear.' It specifies the verb ('gets'), resource ('teams and their IDs'), and data source ('Linear'). However, it doesn't explicitly differentiate from sibling tools like get_profile or search_issues, 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.
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. It doesn't mention prerequisites, timing, or comparisons to siblings like get_profile (which might return user-specific data) or search_issues (which might filter issues by team). This lack of contextual direction limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that searches for issues in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Filter issues by keyword in title or description | |
| limit | No | Maximum number of issues to return (default: 50) | |
| priority | No | Filter issues by priority | |
| skip | No | Number of issues to skip (default: 0) | |
| status | No | Filter issues by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action without mentioning critical details like whether this is a read-only operation, if it requires authentication, potential rate limits, or what the return format looks like. For a search tool with multiple parameters, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function without any unnecessary words. It's front-loaded with the core purpose and wastes no space on redundant information, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the search returns (e.g., issue objects with fields), how results are ordered, or any behavioral constraints. For a search operation in a system like Linear, more context about the operation's scope and results is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the schema itself (e.g., 'keyword' filters by title/description, 'priority' and 'status' have enums, 'limit' and 'skip' have defaults). The description adds no additional parameter information beyond what's already in the schema, meeting the baseline expectation but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'searches for issues in Linear' with a specific verb ('searches') and resource ('issues'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_issue' which might retrieve a single issue, leaving some ambiguity about when to use this versus other issue-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_issue' or 'create_issue'. It lacks any context about appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that updates or deletes an existing comment on an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | The new content for the comment | |
| commentId | Yes | The ID of the comment to update | |
| delete | No | Whether to delete the comment |
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. While it states the tool can update or delete a comment, it lacks critical details: it doesn't specify permissions required, whether updates are reversible, rate limits, error conditions (e.g., invalid commentId), or what happens on deletion (e.g., permanent vs. soft delete). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., by separating update and delete scenarios). Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with three parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or error handling, nor does it explain return values. For a tool that modifies or deletes data, this leaves the agent with insufficient context to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (commentId, comment, delete) well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain parameter interactions (e.g., how 'delete' overrides 'comment'), formats, or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'updates or deletes an existing comment on an issue in Linear'. It specifies the verb (update/delete), resource (comment), and context (issue in Linear), which is specific and actionable. However, it doesn't explicitly distinguish this tool from its sibling 'create_comment', which handles comment creation rather than modification/deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing an existing comment ID), when not to use it (e.g., for creating new comments), or refer to sibling tools like 'create_comment' or 'get_comment'. Usage is implied by the purpose statement but not explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that updates an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | The description of the issue | |
| dueDate | No | The due date of the issue | |
| id | Yes | The ID of the issue to update | |
| parentId | No | The ID of the parent issue, used to create a sub-issue | |
| priority | No | The priority of the issue | no_priority |
| sortOrder | No | The sort order of the issue | |
| status | No | The status of the issue | backlog |
| title | No | The title of the issue | |
| trashed | No | Whether the issue is trashed |
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 states the tool 'updates an issue' which implies a mutation operation, but it doesn't disclose any behavioral traits such as required permissions, whether updates are reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero waste. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every word earns its place, and there's no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 9 parameters, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects like permissions or side effects, provide usage context, or explain return values. For a tool that modifies data in a system like Linear, this leaves significant gaps that could hinder correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or provide examples). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'updates an issue in Linear' with a specific verb ('updates') and resource ('issue in Linear'). It distinguishes from siblings like 'create_issue' (creation vs. update) and 'search_issues' (search vs. update), though it doesn't explicitly mention all siblings. The purpose is clear but could be more specific about what aspects can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing an existing issue ID), when to choose 'update_issue' over 'create_issue' or 'update_comment', or any constraints like permissions. Usage is implied by the name but not explicitly stated, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_commentcreate_issueget_commentget_issueget_profileget_team_idsearch_issuesupdate_commentupdate_issueScored across 9 tools
Every tool has a clearly distinct purpose targeting specific resources and actions in Linear. The tools are well-differentiated by resource type (issue, comment, profile, team) and operation (create, get, search, update), with no overlapping functionality that could cause confusion.
All tool names follow a consistent verb_noun pattern using snake_case throughout. The naming convention is perfectly predictable with verbs like create, get, search, and update consistently applied to appropriate nouns like issue, comment, profile, and team.
With 9 tools, this server is well-scoped for issue management in Linear. Each tool earns its place by covering essential operations without being overwhelming, providing a balanced set that supports core workflows without unnecessary complexity.
The tool set provides excellent CRUD coverage for issues and comments, plus profile and team lookup capabilities. The only minor gap is the lack of a delete_issue tool, though update_issue might handle deletion, and there's no direct tool for listing all issues without search parameters, but agents can work around these limitations effectively.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A Model Context Protocol server for Wix AI tools
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
