Skip to main content
Glama
aikts

Yandex Tracker MCP

Find Issues

issues_find
Read-only

Find Yandex Tracker issues using YQL queries, filtering by assignee, status, tags, dates, or any indexed field.

Instructions

Find Yandex Tracker issues matching a Yandex Tracker Query (YQL) - not limited to queue/date, any indexed field can be used (assignee, status, tags, etc., see the query parameter for the full syntax).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return, default is 1
queryYesSearch query to filter issues using Yandex Tracker Query. # General instructions 1. To search by a specific field use the following syntax: `Description: "some issue description"` 2. Multiple fields should be separated by space: `Description: "some issue description" Created: today()` 3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: "vpupkin","iivanov"` 4. You may specify multiple conditions and combine them using `AND` and `OR` statements, e.g. `<param_1>: "<value_1>" AND <param_2>: "<value_2>"` 5. You may use brackets for complex logical expressions 6. To find issues with exact string matching in the field use this syntax: `Summary: #"Version 2.0"`. If you need to pass special characters - you must escape them using `\` symbol 7. To find issues that don't contain the specified text use this syntax: `Summary: !"Version 2.0"`. If you need to pass special characters - you must escape them using `\` symbol 8. If you need to search by local queue field use the following syntax: `<QUEUE>.<LOCAL_FIELD_KEY>: "<value>", where <QUEUE> is a queue key, <LOCAL_FIELD_KEY> is a local field's key from the `queue_get_fields` tool result (call it with `include_local_fields=true`). 9. For dates use the format YYYY-MM-DD. 10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`. 11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `"Sort By": Created ASC`. 12. For Assignee field and any other field representing a user (such as Author and others) always use username and not name. # Functions These functions may be used, for example: `Created: week()` - return issues created on the current week" * `empty()` - empty value * `notEmpty()` - not empty value * `now()` - current time * `today()` - current date * `week()` - current week * `month()` - current month * `quarter()` - current quarter * `year()` - current year * `unresolved()` - there is no resolution * `me()` - currently logged in user # Examples Find issues in a specific queue: `"Queue": "PROJ"` Find issues by an assignee: `"Assignee": "i.ivanov"` Find not resolved (open, in progress) issues: `"Resolution": unresolved()` Find issues in specific status: `"Status": "Открыт", "В работе"` Find issues created in a specific range: `"Created": "2017-01-01".."2017-01-30"` Find issues created by currently logged in user: `"Author": me()"` Find issues assigned to currently logged in user: `"Assignee": me()"` Find issues created no earlier than 1 week and 1 day before today: `Created: > today() - "1w 1d"` Complete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter
fieldsNoFields to return, in Tracker's own spelling (`storyPoints`, not `story_points`); the standard ones are in this tool's output schema. For a queue's local or the organization's custom fields, pass the field `id` from `queue_get_fields`. An unknown name is dropped silently, so check there if a field comes back missing. Omitting this returns ALL fields.
per_pageNoThe number of items per page. May be decreased if results exceed context window. If there is a change in per_page argument - retrieval must be started over with page = 1, as the paging could have changed.
include_descriptionNoWhether to include the issue description; it can be large. Ignored when `description` is listed in `fields`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsNoTotal items matching the request, across all pages. Null if unknown or filtered - then page on until a page comes back empty.
pagesNoTotal pages at the requested `per_page`; this is the last page when it equals `page`. Null together with `hits`.
valuesNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changedv0.10.0
    • changedInput schema / properties / fields / description
      Previous value: -"Fields to return, in Tracker's own spelling (`storyPoints`, not `story_points`); the standard ones are those of this tool's output schema. For a queue's local or the organization's custom fields, pass the field `id` from `queue_get_fields`. A name Tracker does not know is dropped silently rather than reported, so check that tool if a field comes back missing. Omitting this returns ALL fields, including the queue's local ones."New value: +"Fields to return, in Tracker's own spelling (`storyPoints`, not `story_points`); the standard ones are in this tool's output schema. For a queue's local or the organization's custom fields, pass the field `id` from `queue_get_fields`. An unknown name is dropped silently, so check there if a field comes back missing. Omitting this returns ALL fields."
    • addedOutput schema / $defs / Issue / properties / boards
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "$ref": "#/$defs/IssueBoardReference"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Agile boards the issue shows up on. Tracker fills this in from the boards' own filters - an issue is not assigned to a board directly, so this is read-only. Use the board id with `board_get`, `board_get_columns` or `board_get_sprints`.",
      +  "title": "Boards"
      +}
    • addedOutput schema / $defs / Issue / properties / sprint / description
      Added value: +"Sprints the issue is in. Use `board_get_sprints` to look up the sprints of a board, and pass a sprint id to `issue_update` to move the issue between them."
    • addedOutput schema / $defs / IssueBoardReference
      Added value: +{
      +  "description": "A board an issue shows up on, as nested in an issue record.\n\nTracker spells this one differently from its other references: `name`\ninstead of `display`, and a numeric id. That id is what `board_get`,\n`board_get_columns` and `board_get_sprints` take.",
      +  "properties": {
      +    "id": {
      +      "anyOf": [
      +        {
      +          "type": "integer"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Board identifier, as taken by the `board_get`, `board_get_columns` and `board_get_sprints` tools",
      +      "title": "Id"
      +    },
      +    "name": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Board name",
      +      "title": "Name"
      +    }
      +  },
      +  "title": "IssueBoardReference",
      +  "type": "object"
      +}
  2. Changed11 schema fields changedv0.8.0
    • removedInput schema / $defs
      Removed value: -{
      -  "IssueFieldsEnum": {
      -    "enum": [
      -      "created_at",
      -      "updated_at",
      -      "created_by",
      -      "updated_by",
      -      "version",
      -      "unique",
      -      "key",
      -      "summary",
      -      "description",
      -      "type",
      -      "priority",
      -      "assignee",
      -      "status",
      -      "previous_status",
      -      "deadline",
      -      "components",
      -      "start",
      -      "story_points",
      -      "tags",
      -      "votes",
      -      "sprint",
      -      "epic",
      -      "parent",
      -      "estimation",
      -      "spent"
      -    ],
      -    "title": "IssueFieldsEnum",
      -    "type": "string"
      -  }
      -}
    • changedInput schema / properties / fields / anyOf
      Previous value: -[
      -  {
      -    "items": {
      -      "$ref": "#/$defs/IssueFieldsEnum"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "items": {
      +      "type": "string"
      +    },
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / fields / description
      Previous value: -"Fields to include in the response. In order to not pollute context window - select appropriate fields beforehand. Not specifying fields will return all available."New value: +"Fields to return, in Tracker's own spelling (`storyPoints`, not `story_points`); the standard ones are those of this tool's output schema. For a queue's local or the organization's custom fields, pass the field `id` from `queue_get_fields`. A name Tracker does not know is dropped silently rather than reported, so check that tool if a field comes back missing. Omitting this returns ALL fields, including the queue's local ones."
    • changedInput schema / properties / include_description / description
      Previous value: -"Whether to include issue description in the issues result. It can be large, so use only when needed."New value: +"Whether to include the issue description; it can be large. Ignored when `description` is listed in `fields`."
    • changedInput schema / properties / query / description
      Previous value: -"Search query to filter issues using Yandex Tracker Query.\n# General instructions\n1. To search by a specific field use the following syntax: `Description: \"some issue description\"`\n2. Multiple fields should be separated by space: `Description: \"some issue description\" Created: today()`\n3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: \"vpupkin\",\"iivanov\"`\n4. You may specify multiple conditions and combine them using `AND` and `OR` statements, e.g. `<param_1>: \"<value_1>\" AND <param_2>: \"<value_2>\"`\n5. You may use brackets for complex logical expressions\n6. To find issues with exact string matching in the field use this syntax: `Summary: #\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n7. To find issues that don't contain the specified text use this syntax: `Summary: !\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n8. If you need to search by local queue field use the following syntax: `<QUEUE>.<LOCAL_FIELD_KEY>: \"<value>\", where <QUEUE> is a queue key, <LOCAL_FIELD_KEY> is a local field's key from the `queue_get_local_fields` tool result.\n9. For dates use the format YYYY-MM-DD.\n10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`.\n11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `\"Sort By\": Created ASC`.\n12. For Assignee field and any other field representing a user (such as Author and others) always use username and not name.\n# Functions\nThese functions may be used, for example: `Created: week()` - return issues created on the current week\"\n* `empty()` - empty value\n* `notEmpty()` - not empty value\n* `now()` - current time\n* `today()` - current date\n* `week()` - current week\n* `month()` - current month\n* `quarter()` - current quarter\n* `year()` - current year\n* `unresolved()` - there is no resolution\n* `me()` - currently logged in user\n# Examples\nFind issues in a specific queue: `\"Queue\": \"PROJ\"`\nFind issues by an assignee: `\"Assignee\": \"i.ivanov\"`\nFind not resolved (open, in progress) issues: `\"Resolution\": unresolved()`\nFind issues in specific status: `\"Status\": \"Открыт\", \"В работе\"`\nFind issues created in a specific range: `\"Created\": \"2017-01-01\"..\"2017-01-30\"`\nFind issues created by currently logged in user: `\"Author\": me()\"`\nFind issues assigned to currently logged in user: `\"Assignee\": me()\"`\nFind issues created no earlier than 1 week and 1 day before today: `Created: > today() - \"1w 1d\"`\nComplete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter\n"New value: +"Search query to filter issues using Yandex Tracker Query.\n# General instructions\n1. To search by a specific field use the following syntax: `Description: \"some issue description\"`\n2. Multiple fields should be separated by space: `Description: \"some issue description\" Created: today()`\n3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: \"vpupkin\",\"iivanov\"`\n4. You may specify multiple conditions and combine them using `AND` and `OR` statements, e.g. `<param_1>: \"<value_1>\" AND <param_2>: \"<value_2>\"`\n5. You may use brackets for complex logical expressions\n6. To find issues with exact string matching in the field use this syntax: `Summary: #\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n7. To find issues that don't contain the specified text use this syntax: `Summary: !\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n8. If you need to search by local queue field use the following syntax: `<QUEUE>.<LOCAL_FIELD_KEY>: \"<value>\", where <QUEUE> is a queue key, <LOCAL_FIELD_KEY> is a local field's key from the `queue_get_fields` tool result (call it with `include_local_fields=true`).\n9. For dates use the format YYYY-MM-DD.\n10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`.\n11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `\"Sort By\": Created ASC`.\n12. For Assignee field and any other field representing a user (such as Author and others) always use username and not name.\n# Functions\nThese functions may be used, for example: `Created: week()` - return issues created on the current week\"\n* `empty()` - empty value\n* `notEmpty()` - not empty value\n* `now()` - current time\n* `today()` - current date\n* `week()` - current week\n* `month()` - current month\n* `quarter()` - current quarter\n* `year()` - current year\n* `unresolved()` - there is no resolution\n* `me()` - currently logged in user\n# Examples\nFind issues in a specific queue: `\"Queue\": \"PROJ\"`\nFind issues by an assignee: `\"Assignee\": \"i.ivanov\"`\nFind not resolved (open, in progress) issues: `\"Resolution\": unresolved()`\nFind issues in specific status: `\"Status\": \"Открыт\", \"В работе\"`\nFind issues created in a specific range: `\"Created\": \"2017-01-01\"..\"2017-01-30\"`\nFind issues created by currently logged in user: `\"Author\": me()\"`\nFind issues assigned to currently logged in user: `\"Assignee\": me()\"`\nFind issues created no earlier than 1 week and 1 day before today: `Created: > today() - \"1w 1d\"`\nComplete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter\n"
    • addedOutput schema / properties / hits
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Total items matching the request, across all pages. Null if unknown or filtered - then page on until a page comes back empty.",
      +  "title": "Hits"
      +}
    • addedOutput schema / properties / pages
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Total pages at the requested `per_page`; this is the last page when it equals `page`. Null together with `hits`.",
      +  "title": "Pages"
      +}
    • removedOutput schema / properties / result
      Removed value: -{
      -  "items": {
      -    "$ref": "#/$defs/Issue"
      -  },
      -  "title": "Result",
      -  "type": "array"
      -}
    • addedOutput schema / properties / values
      Added value: +{
      +  "items": {
      +    "$ref": "#/$defs/Issue"
      +  },
      +  "title": "Values",
      +  "type": "array"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "result"
      -]
    • changedOutput schema / title
      Previous value: -"issues_findOutput"New value: +"PaginatedResult[Issue]"
  3. Changed6 schema fields changedv0.6.3
    • changedInput schema / $defs / IssueFieldsEnum / enum
      Previous value: -[
      -  "created_at",
      -  "updated_at",
      -  "created_by",
      -  "updated_by",
      -  "unique",
      -  "key",
      -  "summary",
      -  "description",
      -  "type",
      -  "priority",
      -  "assignee",
      -  "status",
      -  "previous_status",
      -  "deadline",
      -  "components",
      -  "start",
      -  "story_points",
      -  "tags",
      -  "votes",
      -  "sprint",
      -  "epic",
      -  "parent"
      -]New value: +[
      +  "created_at",
      +  "updated_at",
      +  "created_by",
      +  "updated_by",
      +  "version",
      +  "unique",
      +  "key",
      +  "summary",
      +  "description",
      +  "type",
      +  "priority",
      +  "assignee",
      +  "status",
      +  "previous_status",
      +  "deadline",
      +  "components",
      +  "start",
      +  "story_points",
      +  "tags",
      +  "votes",
      +  "sprint",
      +  "epic",
      +  "parent",
      +  "estimation",
      +  "spent"
      +]
    • changedInput schema / properties / query / description
      Previous value: -"Search query to filter issues using Yandex Tracker Query.\n# General instructions\n1. To search by a specific field use the following syntax: `Description: \"some issue description\"`\n2. Multiple fields should be separated by space: `Description: \"some issue description\" Created: today()`\n3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: \"vpupkin\",\"iivanov\"`\n4. You may specify multiple conditions and combine them using `AND` and `OR` statements, e.g. `<param_1>: \"<value_1>\" AND <param_2>: \"<value_2>\"`\n5. You may use brackets for complex logical expressions\n6. To find issues with exact string matching in the field use this syntax: `Summary: #\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n7. To find issues that don't contain the specified text use this syntax: `Summary: !\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n8. If you need to search by local queue field use the following syntax: `<QUEUE>.<LOCAL_FIELD_KEY>: \"<value>\", where <QUEUE> is a queue key, <LOCAL_FIELD_KEY> is a local field's key from the `queue_get_local_fields` tool result.\n9. For dates use the format YYYY-MM-DD.\n10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`.\n11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `\"Sort By\": Created ASC`.\n# Functions\nThese functions may be used, for example: `Created: week()` - return issues created on the current week\"\n* `empty()` - empty value\n* `notEmpty()` - not empty value\n* `now()` - current time\n* `today()` - current date\n* `week()` - current week\n* `month()` - current month\n* `quarter()` - current quarter\n* `year()` - current year\n* `unresolved()` - there is no resolution\n# Examples\nFind issues in a specific queue: `\"Queue\": \"PROJ\"`\nFind issues by an assignee: `\"Assignee\": \"Иван Иванов\"`\nFind not resolved (open, in progress) issues: `\"Resolution\": unresolved()`\nFind issues in specific status: `\"Status\": \"Открыт\", \"В работе\"`\nFind issues created in a specific range: `\"Created\": \"2017-01-01\"..\"2017-01-30\"`\nFind issues created no earlier than 1 week and 1 day before today: `Created: > today() - \"1w 1d\"`\nComplete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter\n"New value: +"Search query to filter issues using Yandex Tracker Query.\n# General instructions\n1. To search by a specific field use the following syntax: `Description: \"some issue description\"`\n2. Multiple fields should be separated by space: `Description: \"some issue description\" Created: today()`\n3. If you need to specify multiple values for the same field - provide them using comma (,), e.g.: `author: \"vpupkin\",\"iivanov\"`\n4. You may specify multiple conditions and combine them using `AND` and `OR` statements, e.g. `<param_1>: \"<value_1>\" AND <param_2>: \"<value_2>\"`\n5. You may use brackets for complex logical expressions\n6. To find issues with exact string matching in the field use this syntax: `Summary: #\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n7. To find issues that don't contain the specified text use this syntax: `Summary: !\"Version 2.0\"`. If you need to pass special characters - you must escape them using `\\` symbol\n8. If you need to search by local queue field use the following syntax: `<QUEUE>.<LOCAL_FIELD_KEY>: \"<value>\", where <QUEUE> is a queue key, <LOCAL_FIELD_KEY> is a local field's key from the `queue_get_local_fields` tool result.\n9. For dates use the format YYYY-MM-DD.\n10. For numerical values you may use comparison operators (>, <, >=, <=): `<param>: ><value>`.\n11. To sort the result specify the `Sort By` directive (you may provide ASC or DESC for the sort order): `\"Sort By\": Created ASC`.\n12. For Assignee field and any other field representing a user (such as Author and others) always use username and not name.\n# Functions\nThese functions may be used, for example: `Created: week()` - return issues created on the current week\"\n* `empty()` - empty value\n* `notEmpty()` - not empty value\n* `now()` - current time\n* `today()` - current date\n* `week()` - current week\n* `month()` - current month\n* `quarter()` - current quarter\n* `year()` - current year\n* `unresolved()` - there is no resolution\n* `me()` - currently logged in user\n# Examples\nFind issues in a specific queue: `\"Queue\": \"PROJ\"`\nFind issues by an assignee: `\"Assignee\": \"i.ivanov\"`\nFind not resolved (open, in progress) issues: `\"Resolution\": unresolved()`\nFind issues in specific status: `\"Status\": \"Открыт\", \"В работе\"`\nFind issues created in a specific range: `\"Created\": \"2017-01-01\"..\"2017-01-30\"`\nFind issues created by currently logged in user: `\"Author\": me()\"`\nFind issues assigned to currently logged in user: `\"Assignee\": me()\"`\nFind issues created no earlier than 1 week and 1 day before today: `Created: > today() - \"1w 1d\"`\nComplete instructions page is available here: https://yandex.ru/support/tracker/ru/user/query-filter\n"
    • addedOutput schema / $defs / Issue / additionalProperties
      Added value: +true
    • addedOutput schema / $defs / Issue / properties / estimation
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Estimation"
      +}
    • addedOutput schema / $defs / Issue / properties / spent
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Spent"
      +}
    • addedOutput schema / $defs / Issue / properties / version
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Version"
      +}
  4. First observedv1.0.0

TDQS

A4.1/5.0
Behavior3/5

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description is consistent with that. The main description adds scope context but does not disclose behavioral details such as pagination resets, silent dropping of unknown fields, or return-size implications; those live in parameter descriptions rather than the tool description itself.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that states what the tool does, narrows the scope ('not limited to queue/date'), gives concrete examples of supported fields, and points to the authoritative syntax source. Every clause earns its place with no wasted words.

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

Completeness5/5

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

The tool has a rich input schema covering all parameters, an output schema for return values, and a readOnlyHint annotation. The main description supplies the missing high-level framing of YQL-based search scope, and the query parameter description provides the full syntax and examples. Nothing essential for correctly selecting and invoking the tool is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly, including the full YQL syntax in the query parameter. The main description merely points to the query parameter and mentions indexed field categories, adding little semantic value beyond the schema itself.

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

Purpose5/5

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

The description uses a specific verb-resource pair ('Find Yandex Tracker issues') and immediately distinguishes this tool from other issue tools by framing it as a YQL search that is 'not limited to queue/date' and can target 'any indexed field.' This clearly separates it from issue_get, issues_count, and queue-scoped tools.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: whenever issues need to be found by YQL across indexed fields rather than by a known ID. It does not explicitly name alternative tools such as issue_get or issues_count, nor does it state when not to use this tool, so it stops short of the fullest guidance.

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

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aikts/yandex-tracker-mcp'

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