Provides tools for managing time entries locally and synchronizing them with an OpenProject instance via its API, including logging, listing, editing, and uploading time entries, as well as querying projects, work packages, activities, and existing time entries.
Click on "Deploy 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., "@@nicola5tor/openproject-timelog Registra 2 horas de hoy arreglando el login, tarea 1234."
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 (Model Context Protocol) for keeping a local time log and syncing it with OpenProject (API v3). Log your work in natural language from Claude Desktop (or another MCP client), review it, and upload it to OpenProject when ready.
Transport: stdio
Local storage: ~/.openproject-timelog/entries.json
Config: OPENPROJECT_URL and OPENPROJECT_API_KEY environment variables
No need to install anything globally: the server runs with npx.
# probarlo directamente
npx @nicola5tor/openproject-timelogOr install it in a project:
npm install @nicola5tor/openproject-timelog
# o
pnpm add @nicola5tor/openproject-timelogRelated MCP server: OpenProject MCP Server
Edit the configuration file (claude_desktop_config.json) and add the
server under mcpServers:
{
"mcpServers": {
"openproject-timelog": {
"command": "npx",
"args": ["-y", "@nicola5tor/openproject-timelog"],
"env": {
"OPENPROJECT_URL": "https://tu-openproject.example.com",
"OPENPROJECT_API_KEY": "TU_API_KEY"
}
}
}
}Restart Claude Desktop after saving.
In OpenProject: My account → Access tokens → API and generate a key. The
server authenticates with Basic auth using the literal user apikey and your key
as the password.
The local-only tools (
log_entry,list_entries,edit_entry,assign_entry,delete_entry,clear_sent) work even if you don't configure OpenProject. The query and upload tools requireOPENPROJECT_URLandOPENPROJECT_API_KEY.
Tool | Description |
| Logs a time entry. Params: |
| Lists entries by status. Param: |
| Edits a pending entry. Params: |
| Assigns a work package to several entries. Params: |
| Deletes a pending entry. Param: |
| Removes all already-sent ( |
Tool | Description |
| Lists projects ( |
| Lists tasks. Optional params: |
| Lists time entry activities ( |
| Queries already-logged hours. Optional params: |
Tool | Description |
| Uploads entries to OpenProject. Optional param |
* = required.
Local ids are UUID v4. Hours are stored in decimal (1.5 = 1h30m)
and converted to ISO 8601 duration (PT1H30M) on upload.
The projectId of an entry, if not specified, is derived from the work package on
upload (an extra call to OpenProject).
The JSON file is written atomically (temp file + rename) and operations are serialized to prevent corruption.
Network / credential / permission errors are returned as readable messages in the tool response, without crashing the server.
You: Log 2 hours of today fixing the login, task 1234. Claude: (calls
log_entrywith description="fix login", hours=2, workPackageId=1234)
You: Log 45 minutes of meeting for me, I'll assign the task later. Claude: (
log_entrydescription="meeting", hours=0.75) — stays pending assignment.
You: What do I have pending to upload? Claude: (
list_entriesstatus="pending")
You: Assign task 1234 to those two meetings. Claude: (
assign_entryentryIds=[...], workPackageId=1234)
You: What activities are there? Set "Development" on everything and upload it. Claude: (
get_activities→edit_entry/assignfor activityId →upload_entries)
You: Clean up what was already uploaded. Claude: (
clear_sent)
npm install # instala deps y compila (prepare -> build)
npm run build # compila TypeScript a dist/
npm start # ejecuta dist/index.jsStructure:
openproject-timelog/
├── src/
│ ├── index.ts # entry point, setup MCP y registro de tools
│ ├── store.ts # CRUD bitácora local (JSON atómico)
│ ├── openproject.ts # cliente API OpenProject v3
│ └── types.ts # interfaces/types
├── package.json
├── tsconfig.json
└── README.mdMIT
Asigna un workPackageId a una o varias entries pendientes (por sus ids).
| Name | Required | Description | Default |
|---|---|---|---|
| entryIds | Yes | ||
| workPackageId | 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 one behavioral constraint (entries must be pending) but omits other important aspects such as whether the operation is reversible, any required permissions, validation behavior, or error handling. For a mutation tool, this is insufficient transparency beyond a single condition.
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, clear sentence with no redundant words or fluff. It is appropriately concise for the tool's simplicity, front-loading the core action and object.
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 2-parameter tool with no output schema, the description conveys the essential action and a key condition (pending entries). However, it lacks details about what happens upon assignment (e.g., return value, side effects, or validation rules) which could be important for correct usage. It is adequate but leaves 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?
Schema description coverage is 0%, so the description must compensate. It only implies that entryIds are the entry identifiers ('por sus ids') and mentions workPackageId by name, but does not explain the domain or constraints beyond what the schema already provides. It adds minimal semantic 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 action ('Asigna' - assigns) and the resource (entries), specifying that it assigns a workPackageId to one or more pending entries based on their IDs. This is a specific verb+resource pair that distinguishes it from sibling tools like edit_entry which would cover a broader set of field changes.
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 usage for pending entries ('entries pendientes') but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions (e.g., when not to use it). It gives some context but lacks explicit guidance on alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Borra de la bitácora local todas las entries con status 'sent'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys the destructive nature (Borra) and specifies the exact condition (status 'sent') and scope (local bitácora). It adds value by clarifying it deletes all such entries, though it doesn't state irreversibility or confirmation prompts. Acceptable 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?
One concise sentence, front-loaded with the core action, no redundancy. It conveys the purpose and scope efficiently.
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?
The tool has no parameters or output schema, so the description only needs to convey the action and scope. It does that clearly. It could mention irreversibility, but the word 'Borra' implies deletion. It's complete for a simple destructive operation.
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?
There are no parameters, so the schema is complete (100% coverage). The description adds context about what gets deleted (all 'sent' entries), which goes slightly beyond the schema, but since there are no params to explain, a baseline of 3 is appropriate.
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 uses a specific verb ('Borra' = deletes) and specifies the resource ('entries con status sent' from the local log), clearly distinguishing it from sibling tools like delete_entry (which deletes a specific entry) and list_entries. The scope is unambiguous.
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 usage (when you want to clear sent entries) but does not explicitly state when to use this tool vs alternatives like delete_entry or log_entry. It gives context (local bitácora) but no exclusions or alternative mentions, so it's adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Borra una entry con status 'pending'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. It only mentions the 'pending' status constraint, which is somewhat useful, but it does not clarify whether the deletion is permanent, if it cascades to related data, or if any authentication or authorization is required. The tool name 'delete_entry' and description imply a destructive operation, but the description offers no additional behavioral details beyond the status filter.
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 concise, a single sentence, and front-loaded with the action 'Borra' (deletes). It could be argued that it is too sparse, but it earns points for being efficient and not wasting words, though it lacks critical details. The title provides additional context but is separate from the description.
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 that there is no output schema and no annotations, the description is quite incomplete. It explains only the status condition but fails to mention return values, errors, side effects, or permission requirements. The tool has a single parameter and a simple action, but as a mutating operation, it should disclose more about consequences, such as irreversibility, which is absent.
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 one parameter 'id' with no description. The description mentions 'pending' status but does not explain that the 'id' must refer to a pending entry or what format the ID should take. Schema description coverage is 0%, and the description adds minimal value: it only clarifies that the entry must have status 'pending', but does not elaborate on the parameter meaning beyond what the schema's property name 'id' already implies.
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 deletes an entry with status 'pending', but it lacks context about what an 'entry' is and how this deletion relates to other entry operations like edit_entry, upload_entries, or clear_sent. The verb 'Borra' (delete) and resource 'entry' are clear, though the distinction from 'clear_sent' (which likely clears sent entries) is not explicit, and the parent title 'Borrar una entrada pendiente' adds nuance but does not differentiate from siblings.
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 like 'edit_entry' or 'clear_sent'. The description only says it deletes a pending entry, implying it's for entries with status 'pending', but it doesn't provide context on when deletion is appropriate or any prerequisites such as permissions or status checks. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edita campos de una entry con status 'pending'. Solo se aplican los campos indicados.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id de la entry | |
| hours | No | ||
| endTime | No | ||
| spentOn | No | ||
| projectId | No | ||
| startTime | No | ||
| activityId | No | ||
| description | No | ||
| activityName | No | Nombre de la actividad tal como aparece en OpenProject; alternativa a activityId, se resuelve automáticamente. Ignorado si activityId ya viene indicado. | |
| workPackageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of transparency. It mentions the 'pending' status constraint and that only indicated fields are applied, but lacks details on side effects, permissions, reversibility, or error handling.
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, consisting of two short sentences that get straight to the point without unnecessary detail.
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?
The description is too brief to provide comprehensive context. It omits information about expected outputs, side effects, or any operational details, making it incomplete for a user to fully understand the tool's behavior.
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 clarify individual parameters. The schema provides some field descriptions (e.g., activityName), but the overall description adds no meaning beyond stating that fields are editable, leaving many parameters unexplained.
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 edits fields of an entry with a 'pending' status, which distinguishes it from other tools. However, it could be more specific about which fields or the nature of the edits.
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 mentions 'Solo se aplican los campos indicados' (only the indicated fields are applied), but it does not explicitly state when to use this tool versus other editing or entry-related tools, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene las actividades disponibles para registrar tiempo. Las actividades son por-proyecto: si pasas workPackageId se listan las de ese contexto; si no, se usa cualquier work package accesible.
| Name | Required | Description | Default |
|---|---|---|---|
| workPackageId | No | Work package cuyo proyecto define las actividades disponibles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It signals a read-only retrieval operation and discloses the conditional scoping/fallback behavior. It does not describe the output shape or auth limitations, but for a simple list retrieval it is reasonably transparent.
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?
Two sentences with no filler: the first states purpose, the second states the only parameter's conditional behavior. It is front-loaded and every sentence adds value.
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 one-optional-parameter read tool with no output schema and no annotations, the description covers purpose and invocation semantics well. It falls short of 5 because it does not specify response format, error cases, or permission requirements.
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 100% for the single parameter, so the baseline is 3. The description adds meaning by explaining the omitted-parameter fallback and the project-scoping purpose, going beyond the schema's static 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 uses the specific verb 'Obtiene' and identifies the resource as 'actividades disponibles para registrar tiempo', clearly distinguishing it from sibling tools like get_work_packages or get_projects. The project-scoping sentence adds further precision.
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 clearly explains when to supply workPackageId (to scope activities to that project) and what happens when it is omitted (any accessible work package is used). It does not explicitly name sibling alternatives or exclusions, so it misses the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene los proyectos disponibles en OpenProject.
| 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 bears full responsibility for disclosing behavior. It only states that projects are 'obtained', implying a read operation but providing no details on pagination, filtering, data volume, or any side effects. This is minimal disclosure for a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence that efficiently states the tool's function without any redundancy. It is front-loaded with the core purpose and contains no filler.
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 no output schema and no annotations, the description should provide a fuller picture of what is returned (e.g., a list of project objects, their fields, or potential errors). It is also redundant with the sibling 'project_list', yet provides no distinguishing information. For a zero-parameter read tool, minimal is typical, but the lack of any output details or usage context makes it incomplete.
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?
There are zero parameters and the schema covers 100% of them (vacuously). The description mentions 'available' projects, which adds slight semantic nuance beyond the schema, but since there are no params, the baseline of 4 is appropriate and the description does not detract.
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 retrieves projects from OpenProject, using a specific verb ('obtiene') and resource ('proyectos'). However, it does not differentiate from sibling tools like 'project_list', which likely serves a similar purpose, so it loses a point for not establishing distinctiveness point.
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?
There is no guidance on when to use this tool versus alternatives like 'project_list' or 'project_use'. The description offers no context on prerequisites, use cases, or restrictions, leaving the agent to guess which tool to invoke among overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta time entries ya registradas en OpenProject, con filtros opcionales.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| projectId | No | ||
| workPackageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. 'Consulta' implies a read-only action and 'ya registradas' clarifies that it targets existing data, but the description does not disclose output format, pagination, default behavior when no filters are supplied, or any permission limitations.
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 short sentence that front-loads the primary purpose, mentions the source system, and notes optional filtering. There is no filler or redundant 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?
The description is minimally adequate for selecting and invoking a simple query tool, but it is not fully complete. It does not clarify default behavior without filters, expected return shape, or constraints around the available filters, especially given there is no output schema and no annotations.
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 only says 'con filtros opcionales,' which adds little beyond the schema's required: 0. Since schema description coverage is 0%, the description should compensate by explaining the purpose of from/to/projectId/workPackageId or how the filters combine, but it does not.
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 queries/consults time entries already registered in OpenProject and supports optional filters. This is a specific verb plus resource and scope, though it does not explicitly differentiate itself from closely named sibling tools like list_entries.
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 intended usage is reasonably implied: use this tool when you need to read or consult existing OpenProject time entries, optionally filtered. However, it does not explicitly mention when to use this tool instead of sibling entry-related tools, nor does it state any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene tareas/work packages, opcionalmente filtradas por proyecto, status o assignee.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Id de status para filtrar | |
| assignee | No | Id de usuario assignee | |
| projectId | No |
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 only states that the tool fetches work packages and can filter them, but it does not disclose behaviors such as pagination, response format, authentication requirements, or how filters combine. This is a minimal disclosure with no extra context beyond the obvious read operation.
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, front-loaded sentence that efficiently conveys the core purpose and filter options without any fluff or repetition. Every word earns its place.
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?
This is a simple list tool with three optional filters and no output schema or annotations. The description does not explain what fields are returned, how filters interact, or any default behavior. For a tool with optional parameters and no output schema, the description leaves significant gaps about the actual usage experience.
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 67% (status and assignee have descriptions, projectId does not). The description mentions filters by project, status, and assignee, which helps map projectId to 'proyecto', adding meaning to that undocumented parameter. However, it adds no format or syntax details beyond the schema, and two parameters already had 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 'Obtiene tareas/work packages, opcionalmente filtradas por proyecto, status o assignee' clearly states the verb (obtiene/get), the resource (work packages/tareas), and the optional filters. It distinguishes itself from sibling tools like get_activities and get_time_entries by naming the specific 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?
The description implies this tool is for fetching work packages with optional filters, but it provides no explicit guidance on when to choose this tool over alternatives like list_entries or get_activities, nor any exclusion conditions. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las entries de la bitácora local filtrando por status, opcionalmente agrupadas.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filtro de estado | pending |
| groupBy | No | Agrupa el resultado por este campo (con subtotales) | |
| onlyActiveProject | No | Si true, muestra solo las entries del proyecto local activo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that this lists local entries (scope) and that grouping produces subtotals, which adds useful context. However, it doesn't disclose the read-only nature explicitly, whether any side effects occur, or what the output format is. The absence of annotations and output schema means more detail could be expected, but the description gives a reasonable overview.
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, front-loaded with the main purpose. It wastes no words and is easy to parse. Every part of the sentence contributes meaning: lists entries, scope (local), filter parameter, and grouping option.
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?
The tool has 3 parameters, all documented in the schema, but it lacks an output schema and annotations. The description covers the essential behavior (filtering, grouping, scope) but does not describe return value structure or any side effects. For a list operation with moderate complexity, the description is adequate but could be more complete with details about the output format or how grouping orders results.
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% (all parameters have descriptions). The description adds the context of 'local' filtering and that grouping includes subtotals, which enhances the schema's basic parameter descriptions. Since schema coverage is high, the baseline is 3, and the description adds minimal extra meaning beyond clarifying the grouping behavior.
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 says 'Lista las entries de la bitácora local filtrando por status, opcionalmente agrupadas' which clearly states the verb (list), resource (entries), and key filtering behavior. It distinguishes from siblings like get_time_entries (which may fetch remote/other entries) and upload_entries (which sends entries), though it doesn't explicitly note the distinction.
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 usage context (local bitácora entries, filtering by status, optional grouping) but does not explicitly state when to use this tool vs alternatives like get_time_entries or upload_entries. It doesn't provide exclusions or alternative suggestions, so the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registra una entrada de horas en la bitácora local. Si no se indica workPackageId queda pendiente de asignar (con assign_entry).
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | Horas en decimal (1.5 = 1h30m) | |
| endTime | No | ||
| spentOn | No | Fecha YYYY-MM-DD (por defecto hoy) | |
| projectId | No | ||
| startTime | No | ||
| activityId | No | ||
| description | Yes | Qué se hizo | |
| activityName | No | Nombre de la actividad tal como aparece en OpenProject (ej. 'Especificación'); alternativa a activityId, se resuelve automáticamente. Ignorado si activityId ya viene indicado. | |
| workPackageId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral load. It discloses one key behavior (pending assignment), but omits other important aspects such as success/failure effects, error handling, or whether the operation is idempotent. For a mutation tool, this is insufficient behavioral 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 one sentence, concise, and directly states key information about behavior and a follow-up action. Every word earns its place.
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 9 parameters, no annotations, and no output schema, the description is too brief to cover important aspects like return value, error handling, or prerequisites. It only hints at one behavioral nuance (pending assignment) but lacks broader context (e.g., how this compares to edit_entry or upload_entries, or what happens on success/failure).
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 only 44% (4 of 9 parameters have descriptions). The description adds semantic detail only for workPackageId (pending assignment) but leaves other parameters (hours, startTime, endTime, projectId, etc.) without clarification. While the schema provides some descriptions, the tool description does not compensate adequately for the undocumented params.
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+resource ('Registra una entrada de horas en la bitácora local') and specifies a key conditional behavior (pending assignment when no workPackageId). It distinguishes this tool as the primary entry-creation action, though it doesn't contrast with sibling tools like upload_entries or list_entries.
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 references assign_entry for handling entries without workPackageId, providing a workflow hint alerting the agent that unassigned entries can be later processed. However, it does not explicitly state when to use this tool over alternatives like upload_entries or edit_entry, nor any preconditions or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea un proyecto local (workspace) para agrupar horas. Define valores por defecto (proyecto de OpenProject, work package y actividad) que se aplican al registrar horas mientras esté activo. Si es el primer proyecto, queda activo automáticamente. Se comparte entre Claude Code y Claude Desktop.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nombre del proyecto local (ej. 'RQ001') | |
| defaultActivityId | No | ||
| defaultWorkPackageId | No | ||
| openprojectProjectId | No | Id del proyecto de OpenProject asociado |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses side effects (defaults apply while active, first project auto-activates, sharing between Claude Code and Desktop), but omits details like duplicate-name handling, whether it changes the currently active project, or what the tool returns.
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?
Three concise sentences in Spanish, each providing necessary information: what it creates, how defaults work, and activation/sharing behavior. No redundant 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?
The description covers core behavior but lacks return-value information and duplicate/overwrite semantics. Given the absence of output schema and annotations, a create operation would benefit from stating what is returned or that existing names are rejected, so the completeness is adequate but not rich.
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 covers 50% of parameters; the description adds meaning by explaining that the OpenProject project, work package, and activity IDs become defaults for logged hours while the project is active. Individual IDs are named clearly, and the 'default' semantics are not obvious from the schema 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?
Clearly states it creates a local project (workspace) for grouping hours, which distinguishes it from project_list, project_use, and project_delete. It also explains the secondary purpose of setting default values for time logging.
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?
Provides clear context: use to create local projects and define defaults that apply while active, with automatic activation only for the first project. It does not explicitly mention when not to use it or point to project_use for selecting an existing project, 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.
Borra un proyecto local. No borra sus entries: solo las desvincula del proyecto.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id del proyecto local a borrar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses the key behavioral nuance: the project is deleted but entries are only unlinked, not deleted. This is valuable beyond what the schema shows.
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 two short sentences, front-loaded with the action and immediately clarifying the critical nuance. Zero wasted 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 tool with one parameter and no output schema, the description is complete. It covers the action, the scope, and the key side-effect. No additional information 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% for the single 'id' parameter, so the schema already documents it. The description adds no additional parameter-specific meaning, but the baseline is 3 given high 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 deletes a local project and explicitly distinguishes it from deleting entries by noting it only unlinks them. This is specific and differentiates from sibling tools like delete_entry.
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 it (when you want to delete a project but keep its entries), but does not explicitly state when not to use it or mention alternatives. It provides some context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los proyectos locales (workspaces) y marca cuál está activo. Distinto de get_projects, que consulta los proyectos de OpenProject.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It states the action (list and mark active) but does not explicitly note that the operation is read-only or non-destructive. While implied, this omission could be ambiguous for agents expecting 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 concise, using two sentences to convey purpose and differentiation. No unnecessary words or 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 list operation with no parameters, the description covers what it lists, what it marks, and how it differs from a similar tool. It is complete for the intended 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 tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It does not hinder understanding.
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 functionality: it lists local projects (workspaces) and marks which one is active. It also distinguishes itself from get_projects, providing immediate clarity on its unique scope.
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 explicitly contrasts with get_projects, indicating when to use this tool (for local projects) versus the alternative (OpenProject projects). This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marca un proyecto local como activo. Las nuevas horas (log_entry) se crean dentro de él y toman sus valores por defecto.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id del proyecto local a activar |
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 discloses a key behavioral trait: activating a project affects where new log entries are created and their default values. However, it does not mention whether this action is reversible, if it has side effects on existing entries, or if it requires specific permissions. The description adds some behavioral context but not comprehensive 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 concise and front-loaded: it states the primary action in the first sentence and adds a brief consequence in the second. Every sentence adds value, and there is no redundant or filler content. It is appropriately sized for a simple tool with one parameter.
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 (one parameter, no output schema, no annotations), the description is reasonably complete. It explains the purpose and the main behavioral consequence (new log entries are created within the active project). However, it could be more complete by mentioning whether the activation is persistent, if there is a way to deactivate, or if there are any prerequisites. The description is adequate but not exhaustive.
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% (the 'id' parameter is described as 'Id del proyecto local a activar'). The description does not add additional parameter semantics beyond what the schema provides, but since the schema already covers the single parameter, a baseline of 3 is appropriate. The description does not explain the format or constraints of the id, but the schema's description is sufficient.
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: 'Marca un proyecto local como activo' (Marks a local project as active). It specifies the resource (local project) and the action (mark as active), and distinguishes it from sibling tools like project_create, project_delete, and project_list by focusing on the activation state rather than CRUD operations.
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 this tool: when you want to set a project as active so that new hours (log_entry) are created within it. However, it does not explicitly state when not to use it or mention alternatives. The context about log_entry creation provides some usage context, but it lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera un HTML autocontenido (stats, filtros por grupo y tabla) con las entries de la bitácora y lo escribe en un fichero temporal. Devuelve la ruta del fichero (no el HTML) para publicarla con la tool Artifact, evitando gastar tokens en volcar el HTML en la respuesta.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Título de la galería | |
| status | No | Filtro de estado | pending |
| groupBy | No | Campo por el que agrupar y colorear las entries | workPackageId |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: it writes a temporary file, returns a path instead of the HTML content, and explains why (to save tokens). This covers the main side effects, though it omits details about cleanup or failure modes.
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 two sentences: the first states the core action and the second explains the return value and rationale. It is front-loaded, concise, and contains no redundant 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?
The tool has optional parameters and no output schema, but the description sufficiently conveys its purpose, side effect (temp file creation), and return value (path). It also references the Artifact tool for integration. Minor gaps include lack of prerequisites or error conditions, but overall it is reasonably 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?
The input schema provides 100% coverage with descriptions for all three parameters (title, status, groupBy). The description adds minimal parameter-specific detail beyond mentioning 'filtros por grupo', so it doesn't significantly enhance the schema's meaning.
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 generates a self-contained HTML document with stats, group filters, and a table from log entries, writes it to a temporary file, and returns the file path. This specific verb ('Genera') and resource ('HTML autocontenido') distinguish it from sibling tools focused on CRUD operations.
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 gives clear usage context by explaining that the returned path is meant to be published with the Artifact tool and justifies this approach by avoiding token costs. While it doesn't explicitly name alternative tools or provide when-not-to-use guidance, the intended use case is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sube a OpenProject las entries indicadas (o todas las pending con workPackageId si se omite entryIds). Cada entry necesita workPackageId y activityId.
| Name | Required | Description | Default |
|---|---|---|---|
| entryIds | No | Ids a subir; si se omite, sube todas las pending con workPackageId asignado |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions selection logic and required fields (workPackageId, activityId), but does not state what happens to entries after upload (e.g., marked as sent, deleted, or any side effects). For a mutation tool, this is a significant transparency gap.
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 two sentences, front-loaded with the main verb and resource, and wastes no words. It concisely conveys the action, the parameter behavior, and required entry fields.
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 one parameter, 100% schema coverage, and no output schema, the description covers the core functionality and edge case (omitting entryIds). However, it lacks important contextual details about post-upload side effects or return behavior, which would be necessary for an agent to fully anticipate the tool's impact.
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 only parameter, entryIds, is already well documented in the schema with a description that matches the tool description. The description adds context about entry prerequisites (workPackageId and activityId), but this does not directly enhance the parameter semantics beyond what the schema provides.
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 action: 'Sube a OpenProject las entries indicadas' (uploads specified entries to OpenProject). It also clarifies the fallback behavior when entryIds is omitted, which distinguishes it from sibling tools like log_entry or delete_entry that perform different operations.
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 explains when to upload specific entries versus all pending ones, but it does not explicitly state when to use this tool over alternatives like log_entry. The context of uploading entries is implicit, but no exclusions or alternative recommendations are provided.
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.
v0.2.1assign_entryclear_sentdelete_entryedit_entryget_activitiesget_projectsget_time_entriesget_work_packageslist_entrieslog_entryproject_createproject_deleteproject_listproject_userender_galleryupload_entriesScored across 16 tools
Tools are mostly distinct: local entry operations, remote OpenProject reads, upload/reporting, and workspace project management occupy clear separate roles. The get_projects vs project_list pair is the only potential ambiguity, though descriptions explicitly distinguish remote projects from local workspaces.
The majority follow a clear verb_noun snake_case pattern (get_work_packages, log_entry, upload_entries). The project_* group (project_create, project_list, project_use, project_delete) reverses the order to noun_verb, which is internally consistent but a visible deviation.
16 tools is at the upper edge for a focused server, but the scope includes local entries, OpenProject synchronization, remote querying, reporting, and local workspace management. Each tool has an identifiable purpose, so none feels redundant, though the surface is slightly heavy.
The core local-entry lifecycle is complete: create, list, edit, delete, assign, upload, and clean up. Minor gaps such as no way to update local project defaults and no remote time-entry edit/delete are present but don't block the main log-and-upload workflow.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
MCP server providing attendance data queries via the CloudTime API.
An MCP server that provides access to Testiny projects, test cases and test runs
