issue_get_worklogs
The time logged on one or more issues
How to use it
issue_get_worklogs is exposed by the Yandex Tracker MCP MCP server. Add the server to your MCP client (Claude Desktop, Cursor, Windsurf and others), and the issue_get_worklogs tool becomes available to the model automatically. See the full listing for setup details and every tool this server provides.
Install Yandex Tracker MCP
claude mcp add yandex-tracker docker "run --rm -i -e TRACKER_TOKEN=your_tracker_token_here -e TRACKER_CLOUD_ORG_ID=your_cloud_org_id_here -e TRACKER_ORG_ID=your_org_id_here -e TRANSPORT=stdio ghcr.io/Other tools in Yandex Tracker MCP (66)
Reads take entityid and fields; the find tools take input, filter, orderby, orderasc, rootonly, page, perpage. Create and update take summary (required on create), description, lead, teamusers, clients, followers, start (goals have none), end, tags, entitystatus, parententity, teamaccess and links,
One board with autoFilterSettings (what it collects), estimateBy, useRanking and its working calendar
The board's columns with the issue statuses that land in each
The board's sprints with status (draft, inprogress, released, archived) and planned/actual dates
The organization's agile boards; returns {boards, nextcursor}
(int, required): Comment ID
One comment template by id
The comment templates, with the template text and its summonees / maillistSummonees
Create a component in a queue
Delete a component
One component with queue, lead, assignAuto and version
Change name, description, lead or auto-assign flag; omitted fields keep their value, clearlead removes the lead
(date, optional): Version due date in YYYY-MM-DD format
(string, required): ISO-8601 duration (e.g. PT1H30M)
(array of strings, optional): Fields to expand in the response. Available options: all, projects, components, versions, types, team, workflows, fields, issueTypesConfig
(string, optional): Filter the changelog by a field key (e.g. status)
(optional): Fields to include in the response (e.g., ["key", "name"]). Helps optimize context window usage by selecting only needed fields. If not specified, returns all available fields.
(array of IssueUpdateFollower, optional): Followers - array of objects with id (string, user ID or login)
Every global field of the organization, with its schema and type
Every issue type, for the type argument of issuecreate / issueupdate
Every priority, with id, key, name and order
Every resolution, for the resolutionid of issueclose
Every issue status the organization defines
(boolean, optional, default: true): Whether to include issue description in the result. Can be large, so use only when needed.
(boolean, optional, default: true): Whether to include queue-specific local fields
(boolean, optional, default: true): Add comment author to followers
(string, required): ID or key of the issue to link to (e.g. "TEST-123")
Add a comment; summonees is what notifies a user, an @login in the text notifies nobody
Link two issues
Delete a comment
Remove a link
One issue by key: the full record, the current version included
A page of comments, oldest first; returns {comments, nextcursor}
Links to related, blocking and duplicate issues
The web URL of an issue
(string, format: "QUEUE-123")
One issue template by id
The issue templates, with the fieldTemplates values they prefill; returns {values, hits, pages}
Edit a comment
(int, required): Link ID (as returned by issuegetlinks)
(array of strings, optional): Mailing lists to summon (emails)
(string, optional): Use md for YFM (markdown)
(IssueUpdateParent, optional): Parent issue reference with id (string) and/or key (string, e.g., 'QUEUE-123')
(optional): Number of items per page (default: 100)
(string, optional): Priority key (from getpriorities tool)
returns that queue's templates plus the ones bound to no queue, which are usable everywhere. TRACKERLIMITQUEUES applies: templates of a restricted queue are omitted from the listings and rejected on direct access, while templates without a queue stay visible.
Create a version in the queue
The queue's components as full objects, with lead, auto-assign flag and version; queuegetmetadata with expand: ["components"] gives ids and names only
The fields configured on the queue, local ones included; schema.required marks the mandatory ones
Name, description, default type and priority, plus whatever expand asks for
The tags defined in the queue
The queue's versions, with dates and status
(string, required): Queue key like "SOMEPROJECT"
Every queue the token may see; returns {values, hits, pages}
(string, required): Link type describing how issueid relates to the linked issue. One of: relates, is dependent by, depends on, is subtask for, is parent task for, duplicates, is duplicated by, is epic of, has epic
(string, required): The resolution ID to set when closing (e.g., 'fixed', 'wontFix', 'duplicate')
(array of IssueUpdateSprint, optional): Sprint assignments - array of objects with id (int) field
(string, required): Issue title/summary
(array of strings, optional): Users to summon (logins or IDs). This is the API way to mention/call users (notifications are triggered by this field, not by @login in text).
(array of strings, optional): Issue tags
(string, required): The transition ID to execute. IMPORTANT: Must be one of the IDs returned by issuegettransitions tool
One user by login or uid
The user the current token belongs to
A page of the organization's users; returns {values, hits, pages}
Find users by login, email or real name
(int, required): Worklog entry ID