PR-CY MCP

get_project_notes

Получить заметки по проекту — пользовательские отметки о работах на сайте (выкатили релиз, поменяли robots.txt и т.п.), которые помогают связать изменения метрик с действиями. Заметки отсортированы по дате по убыванию (новые первыми), удалённые не отдаются. Границы периода включительные; если период не задать, вернутся все заметки проекта за всё время. Эндпоинт не умеет пагинацию и всегда отдаёт весь список за период, поэтому limit/offset применяются на стороне инструмента: они уменьшают ответ, но не нагрузку на API — на долгоживущем проекте лучше сузить период. Удаление заметок инструментами не поддерживается.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "get_project_notes"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Количество заметок на странице.
`offset`	No	Смещение выборки заметок.
`date_to`	No	Конец периода в формате YYYY-MM-DD, включительно — заметки этого дня входят в выборку. Сравнивается с датой самой заметки (поле date). Должно быть >= date_from. У событий таймлайна границы другие: там date_to не включительна.
`date_from`	No	Начало периода в формате YYYY-MM-DD, включительно. Сравнивается с датой самой заметки (поле date), а не с датой её создания. Должно быть <= date_to.
`project_id`	Yes	Идентификатор проекта. Если известен только домен, получи проект через get_user_project_by_domain и возьми id оттуда.

Output Schema

Name	Required	Description
`notes`	Yes	Заметки, отсортированные по дате по убыванию (новые первыми)
`total`	Yes	Общее число заметок проекта за период, без учёта limit и offset
`has_more`	Yes	Остались ли заметки за пределами текущей страницы. Точное значение: эндпоинт отдаёт весь список за период, а limit/offset применяются на стороне инструмента

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden, and it does disclose useful traits: sort order, exclusion of deleted notes, inclusive period boundaries, and that deletion is not supported via tools. What is missing is any statement about required permissions or how the endpoint behaves on very large projects beyond the recommendation to narrow the period. A 3 reflects solid but incomplete behavioral disclosure for an un-annotated read tool.

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

Conciseness4/5

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

Single dense paragraph, front-loaded with purpose, then constraints, then operational caveats. Every sentence carries information, though the pagination explanation is somewhat verbose and could be tightened. No filler or repetition.

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?

For a read-only list tool with an output schema, the description covers purpose, filtering defaults, ordering, exclusions, and the important non-obvious quirk that limit/offset do not reduce API load. Nothing an agent needs to invoke it correctly is absent.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: limit/offset are client-side windowing rather than true pagination, and omitting the period returns all notes for all time. It also clarifies that the date fields compare against the note's own date, which the schema also states. The added pagination semantics make it genuinely more informative than the schema alone.

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?

States a concrete verb and resource ("Получить заметки по проекту") and immediately defines what a note is (user marks about site work such as releases or robots.txt changes) and why they matter. An agent can tell these are manual project annotations rather than automatic events or metrics data.

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?

Gives concrete operating guidance: results are sorted newest-first, deleted notes are excluded, omitted period returns everything, and limit/offset are applied tool-side so they shrink the response but not API load — with the recommendation to narrow the period on long-lived projects. It does not explicitly contrast the tool with the sibling get_project_events beyond a passing remark about timeline boundaries.

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

All PR-CY MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?