Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@projectlibre-mcp Summarize my project.pod file"
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.
MCP server para leer, analizar, crear y editar proyectos de ProjectLibre desde Claude, vía la librería MPXJ.
Lee .pod (nativo de ProjectLibre) y .xml (MS Project / MSPDI) directamente.
Escribe .xml (MSPDI). Para ver los cambios en ProjectLibre: File → Open el .xml generado (y, si quieres, Save As → .pod).
No se puede escribir .pod directamente (formato propietario); por eso la escritura produce .xml.
Related MCP server: FS-MCP
Java (JDK 21 recomendado; JAVA_HOME configurado).
uv.
uv syncclaude mcp add -s user projectlibre -- uv run --directory "C:\Users\osyanne\Documents\Claude\Projects\projectlibre-mcp" projectlibre-mcpLectura / análisis (aceptan .pod o .xml):
summarize_project(file) — resumen: nombre, fechas, # tareas/recursos, hitos.
list_tasks(file, only_critical=False) — tareas con id, nombre, fechas, duración, %, predecesoras, recursos.
get_task(file, task_id) — detalle de una tarea.
list_resources(file) — recursos y sus asignaciones (tarea, unidades, trabajo).
critical_path(file) — ruta crítica y holgura por tarea.
Creación / edición (escriben .xml MSPDI para importar):
create_project(name, start_date, tasks, out) — proyecto desde cero. tasks = lista de {name, duration_days, predecessors?, resource?, percent_complete?, is_milestone?}. predecessors admite índices 1-based o nombres.
add_task(file, name, duration_days, predecessors?, resource?, out?)
update_task(file, task_id, fields, out?) — fields: name, duration_days, percent_complete, is_milestone, start.
remove_task(file, task_id, out?)
set_dependency(file, predecessor_id, successor_id, type="FS", lag_days=0, out?) — type ∈ {FS, SS, FF, SF}.
assign_resource(file, task_id, resource_name, units=100, out?)
En las herramientas de edición,
outes opcional si la entrada ya es.xml(se sobrescribe); si la entrada es.pod,out(.xml) es obligatorio. Las fechas usan formatoYYYY-MM-DD; las duraciones, días laborables.
Exporta tu proyecto desde ProjectLibre o crea uno con create_project.
Pídele a Claude que lo lea/analice/edite — los cambios se guardan en un .xml.
File → Open ese .xml en ProjectLibre para ver/persistir el resultado.
La escritura genera .xml (requiere abrirlo en ProjectLibre para persistir como .pod).
critical_path lee valores de holgura/crítica ya calendarizados (archivos reales de ProjectLibre).
Detección automática de sobreasignación de recursos: trabajo futuro.
uv run pytest -q # suite completaStack: Python 3.12 · mcp (FastMCP) · mpxj (JPype sobre JDK 21) · pytest. Arquitectura en capas: jvm → io → model → reader/writer → server.
Agrega una tarea a un proyecto y guarda el resultado en .xml (out o el .xml de entrada).
| Name | Required | Description | Default |
|---|---|---|---|
| out | No | ||
| file | Yes | ||
| name | Yes | ||
| resource | No | ||
| predecessors | No | ||
| duration_days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions saving results to XML, which indicates file modification, but it does not disclose other behavioral traits such as whether it overwrites or appends, validation steps, or error handling. With no annotations, the description should convey more behavioral context.
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 sentence, making it concise, but it lacks structure such as separate sections or bullet points. While brevity is good, it omits essential details.
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 six parameters, no annotations, and no output schema, the description is incomplete. It fails to explain required parameters, return values, file behavior, or potential errors, leaving significant gaps for the agent.
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 0%, and the description adds no meaning to any of the six parameters. It does not mention file, name, duration_days, resource, predecessors, or out, leaving the agent without any extra guidance beyond the schema field names.
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 adds a task to a project and saves the result to an XML file. It uses a specific verb ('add') and resource ('task to a project'), and it distinguishes from sibling tools like create_project, update_task, and remove_task.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It only states the action without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Asigna un recurso a una tarea (lo crea si no existe) y guarda en .xml.
| Name | Required | Description | Default |
|---|---|---|---|
| out | No | ||
| file | Yes | ||
| units | No | ||
| task_id | Yes | ||
| resource_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions creation of resource if not exists and saving to .xml, but does not detail side effects like overwriting, permissions required, error scenarios, or the format of the .xml file.
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 only one sentence, which is efficient but omits critical details. It is under-specified rather than concise, lacking parameter explanations and usage context.
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 no output schema, 5 parameters, and the complexity of assigning resources to tasks, the description is inadequate. It does not explain return values, what the .xml file represents, or how units/out are used.
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 0%, and the description does not explain any of the 5 parameters (file, task_id, resource_name, units, out). Only resource and task are referenced implicitly. No additional meaning beyond the schema names.
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 verb 'assigns' and the resource (resource to task), and notes that it creates the resource if not exists. This distinguishes it from sibling tools like add_task or list_resources.
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?
No explicit guidance on when to use this tool versus alternatives, such as when to use list_resources first or when to use add_task. Only implicit assumption from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea un proyecto desde cero y escribe un .xml que se abre en ProjectLibre.
start_date en formato YYYY-MM-DD. tasks: lista de objetos con
name, duration_days y opcionales predecessors (índices 1-based o nombres),
resource, percent_complete, is_milestone. out debe terminar en .xml.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| name | Yes | ||
| tasks | Yes | ||
| start_date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the main action and output format (XML) but lacks details on side effects, prerequisites, error handling, or whether it overwrites existing files. Adequate but with notable gaps.
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 short, efficiently front-loading the purpose and then detailing parameters in a structured bullet-like format. Every sentence adds value with no waste.
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 absence of output schema and annotations, the description covers the tool's function, output format, and parameter details adequately. However, it omits information about return values and error scenarios, leaving some contextual gaps for a creation tool of moderate complexity.
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 0%, so the description compensates well by explaining each parameter: name, start_date (format), tasks (list objects with fields), and out (must end in .xml). It adds meaning beyond the schema's bare titles, though some task fields are only listed without full explanation.
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 creates a project from scratch and writes an XML file for ProjectLibre. It uses a specific verb ('creates') and resource ('project'), and distinguishes from sibling tools which are sub-operations like add_task or assign_resource.
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?
No guidance is provided on when to use this tool versus alternatives. The description implies use for new project creation but does not mention exclusions or when not to use it, such as for modifying existing projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ruta crítica y holgura (slack) por tarea. Requiere un archivo ya calendarizado.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects (e.g., whether the tool is read-only), limitations, or what happens if the file is not scheduled. The basic verb 'require' implies a constraint 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences—and front-loads the purpose. Every word is necessary, and there is no redundancy.
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 simple tool with one parameter and no output schema, the description is minimally adequate. It conveys the core function and a prerequisite, but lacks details on the parameter format and return value, leaving some ambiguity for an AI agent.
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?
With schema description coverage at 0%, the description should add meaning to the parameter 'file'. However, it only states 'Requires a file already scheduled' without clarifying what 'file' refers to (ID, path, etc.). No added semantics beyond the schema.
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 computes critical path and slack per task, and it specifies a prerequisite (a scheduled file). This distinct purpose separates it from sibling tools like list_tasks or add_task.
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?
It explicitly mentions the requirement for an already scheduled file, which guides the agent on necessary preconditions. However, it does not provide explicit alternatives or when-not-to-use scenarios, though sibling context implies the tool is used after scheduling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detalle de una tarea por su id (uniqueID).
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only implies a retrieval operation via 'Detalle de una tarea'. It does not disclose any behavioral traits like required permissions, side effects, or output format.
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?
Single sentence is concise, but it lacks structure and only covers the core purpose. Could benefit from brief parameter context.
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 2-parameter tool with no output schema or annotations, the description is overly minimal. It fails to explain the 'file' parameter and provides no details about the task details returned.
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 coverage is 0%, yet the description only explains the task_id parameter ('por su id'). The 'file' parameter remains completely unexplained, despite being 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?
Description clearly states the tool retrieves task details by ID. Distinguishes from sibling tools like add_task, update_task, and list_tasks, which involve different actions. However, it does not explicitly declare the operation as read-only.
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?
No guidance on when to use this tool versus alternatives, such as list_tasks for all tasks. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los recursos y sus asignaciones (tarea, unidades, trabajo).
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the basic purpose but omits details like read-only behavior, error handling, or output format.
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 one short sentence, but it still conveys the essential purpose without unnecessary words.
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 simple list tool with one parameter and no output schema, the description is minimally adequate but lacks details on how to use the 'file' parameter and what the output contains.
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 0%, and the description does not explain the 'file' parameter at all, adding no meaning beyond the schema.
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 lists resources and their assignments, using a specific verb and resource. However, it does not differentiate from sibling tools like 'assign_resource' or 'list_tasks'.
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?
No guidance is provided on when to use this tool versus alternatives. Usage is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las tareas con id, nombre, fechas, duración, %, predecesoras y recursos.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| only_critical | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states what fields are listed but does not disclose any behavioral traits like read-only nature, data source, or potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It effectively communicates the core purpose.
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 simple list tool, the description is culturally complete in clearly stating the output fields, but it omits explanation of required parameter 'file' and optional 'only_critical', which reduces completeness for a functional workflow.
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 description does not explain the parameters beyond listing fields. With 0% schema coverage, the description adds no meaning to the 'file' or 'only_critical' parameters.
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 verb 'Lista' (lists) and the resource 'tareas' (tasks), and specifies the fields returned (id, name, dates, etc.), which distinguishes it from sibling tools like get_task (singular) and add_task.
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 such as critical_path or summarize_project. There are no explicit context hints or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Elimina una tarea por id y guarda el resultado en .xml.
| Name | Required | Description | Default |
|---|---|---|---|
| out | No | ||
| file | Yes | ||
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It only states deletion and output to .xml, but does not disclose destructive nature, authorization needs, side effects, or what 'saves result' means. This is minimal 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 sentence, which is concise but lacks structure. It conveys the basic action without waste, but could benefit from additional context without becoming verbose.
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?
With no annotations, no output schema, and 0% parameter coverage, the description is far from complete. It fails to explain side effects, parameter roles, or the nature of the XML output, leaving significant gaps for an agent to use correctly.
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 0% description coverage for its three parameters. The description does not explain the meaning of 'file' or 'out', nor how they relate to the XML output. No added value beyond the schema's bare names.
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 verb 'elimina' (delete/remove) and the resource 'tarea' (task) by id. It also adds specificity by mentioning saving the result in .xml, distinguishing it from other sibling tools like add_task or get_task.
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, no prerequisites, and no scenarios where it should not be used. The agent is left to infer usage solely from the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea una dependencia entre tareas. type ∈ {FS, SS, FF, SF}.
| Name | Required | Description | Default |
|---|---|---|---|
| out | No | ||
| file | Yes | ||
| type | No | FS | |
| lag_days | No | ||
| successor_id | Yes | ||
| predecessor_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should fully disclose behavioral traits. It briefly explains the type parameter but omits side effects, authorization needs, or what happens if a dependency already exists. The description lacks depth on 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 very short (one sentence) and front-loaded with the verb and resource. It is concise but could be slightly more structured by separating purpose from parameter details.
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?
With 6 parameters (3 required), no output schema, and no annotations, the description is too minimal. It does not explain the concept of dependencies, lag days effect, or the file parameter. A more comprehensive description is needed for adequate context.
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 0%; parameters have only titles and types. The description adds meaning to the 'type' parameter by listing values, but does not explain 'file', 'lag_days', 'out', or the IDs. It insufficiently compensates for the lack of schema descriptions.
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 creates a dependency between tasks ('Crea una dependencia entre tareas'). It specifies the type parameter values, distinguishing it from sibling tools like add_task or assign_resource.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for creating task dependencies, but does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resumen del proyecto: nombre, fechas, # tareas/recursos e hitos.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool is read-only (summary), but does not disclose any specific behavioral traits like required permissions, data sensitivity, or side effects. Minimal disclosure.
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 sentence, making it concise. However, it is written in Spanish which may reduce clarity for English-speaking agents. Front-loaded with purpose.
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 simple tool with one parameter and no output schema, the description covers the output content but leaves the parameter completely undocumented. It is minimally viable but not complete.
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 coverage is 0%, and the description does not explain the 'file' parameter. The agent cannot infer what value to provide for 'file' from the description alone.
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 it provides a project summary including name, dates, task/resource counts, and milestones. This distinguishes it from sibling tools that perform specific actions like adding tasks or assigning resources.
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 implies when to use (to get a high-level overview), but does not provide explicit guidance on when not to use or suggest alternatives. Siblings differ in function, so usage context is clear but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modifica campos de una tarea (name, duration_days, percent_complete, is_milestone, start).
| Name | Required | Description | Default |
|---|---|---|---|
| out | No | ||
| file | Yes | ||
| fields | Yes | ||
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as side effects, required permissions, or idempotency. It only states it modifies fields without further detail.
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?
Single sentence with no unnecessary words, effectively front-loaded with the core action and scope.
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?
No output schema, no description of return values or confirmation, and no examples. For a 4-parameter tool with 3 required, more context is needed for safe use.
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 description adds meaning for the 'fields' parameter by listing modifiable attributes, but fails to explain the 'out', 'file', and 'task_id' parameters beyond their schema names, despite 0% schema description coverage.
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 modifies a task (verb and resource) and lists specific fields (name, duration_days, etc.), distinguishing it from sibling tools like add_task, get_task, or remove_task.
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?
No guidance on when to use this tool versus alternatives, no prerequisites mentioned, and no context for appropriate usage.
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. Dates show when Glama detected each change.
v0.1.0add_taskassign_resourcecreate_projectcritical_pathget_tasklist_resourceslist_tasksremove_taskset_dependencysummarize_projectupdate_taskEach tool has a clearly distinct purpose: task CRUD, resource assignment, dependency management, critical path, and project summary. No two tools overlap in functionality; descriptions clearly differentiate them.
Tool names follow a consistent verb_noun pattern (e.g., add_task, list_tasks) except for critical_path, which is a noun phrase. This minor deviation does not significantly impair predictability.
With 11 tools covering project creation, task/resource management, dependencies, and analysis, the count is well-scoped for a project management server. Each tool earns its place without being overwhelming.
The tool surface covers core CRUD for tasks and project creation, but lacks resource update/delete tools and a full project retrieval tool (beyond summary). These gaps may hinder workflows requiring resource lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Project management MCP for AI agents with safe task reads and writes.
PDF tools for Claude: merge, split, compress, convert, OCR & more. Requires a PDFHaul API key.
Read, edit, publish, and preview your pepita websites from Claude.
Draft-safe project planning: tasks, dependencies, resources, schedules and cost metrics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Osyanne/projectlibre-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
