Tool reference

Generated from @myna-sh/mcp 0.17.0 by introspecting the real server (createServer()).

If a tool below is missing from your client's tool list, your install is older than this page — see Versioning and compatibility.

All tools accept an optional project argument (project id, slug, or configured name; omit to use the default project). Read-only tools are marked; destructive tools additionally require confirm: true in their input.

Tools

myna_list_projects

List projects in an organization. (read-only)

myna_get_project

Fetch a single project's details. (read-only)

myna_list_collections

List the deployed collections in a project. (read-only)

myna_get_collection_schema

Fetch the latest canonical schema for a collection. (read-only)

myna_list_entries

List entries in a collection. (read-only)

myna_get_entry

Fetch one entry by "/" or entry id. The result carries openChangeSets: every open change set already staging a change to this entry, with the fields each one touches, and contendedFields where more than one does. Read it before writing — a collision found here costs nothing, and the same overlap found by the conflicts check costs whatever you wrote first. (read-only)

myna_create_change_set

Open a new change set to group entry and asset operations. (write)

myna_get_change_set

Fetch a change set and its items. (read-only)

myna_create_entry

Create a draft entry. Does not publish. (write)

myna_update_entry

Update a draft entry. Does not publish. (write)

myna_delete_entry

Stage an entry deletion on a change set. Requires confirm=true. Takes effect only on publish. (destructive)

myna_upload_asset

Upload an asset from base64 bytes or a local file path via the presigned flow. The result reports any existing image that looks like the same picture (similar), including resized or re-encoded copies a checksum cannot match — reference one of those and delete this upload rather than leaving the library with two. (write)

myna_validate_change_set

Validate every changed resource in a change set against the deployed schemas. (read-only)

myna_create_preview

Create one preview URL for a change set (or entry). Never publishes. (write)

myna_publish_change_set

Atomically publish a change set. Requires confirm=true and content:publish scope. (destructive)

myna_get_entry_revisions

List the immutable revisions of an entry. (read-only)

myna_get_entry_references

Show reference integrity for an entry: which entries reference it (backlinks) and which entries it references, with publish state. Useful before unpublishing or deleting. (read-only)

myna_restore_revision

Restore a historical revision into a new draft revision. Requires confirm=true. (destructive)

myna_schedule_change_set

Schedule a change set to publish atomically at a future time, or cancel its schedule. Requires confirm=true and content:publish scope. Schedule status is readable via myna_get_change_set (scheduledAt). (destructive)

myna_get_change_set_review

Fetch a change set's reviews, comments, and latest automated check run in one call. (read-only)

myna_review_change_set

Record an approve or request-changes review decision on a change set. Requires content:review scope. (write)

myna_comment_on_change_set

Add a comment to a change set, optionally anchored to an entry field. (write)

myna_run_change_set_checks

Run the built-in automated checks against a change set and return the results: schema validation, reference integrity, conflicts, duplicate slugs, and the policy rules each collection declares for itself. Read a collection's policy with myna_get_collection_schema before writing, so you satisfy the rules rather than discovering them here. (write)

myna_list_change_sets

List change sets in a project, newest first, optionally filtered by status (open, ready, published, closed). Use this to find work already in progress before starting a new change set. (read-only)

myna_diff_change_set

Show what a change set would change, field by field: per item, the operation, the collection and slug, and every changed field with its before and after value. Long prose fields also carry segments — an ordered list of equal/insert/delete runs — so a rewritten body reads as the words that moved rather than as two walls of text. This is what a reviewer reads; use it to summarize your own work or to review someone else's. (read-only)

myna_rebase_change_set

Replay this change set's edits on top of what is published now. An entry can be staged on several open change sets at once, so another change set publishing first leaves yours describing a revision that is no longer current — publish refuses that rather than merging silently. This performs the field-level three-way merge: fields the other side did not touch are replayed automatically, and fields you both changed are reported as conflicts. Refuses by default rather than discarding anyone's work; pass onConflict to take one side. Use dryRun=true first to see what would happen. Rebasing writes new drafts, so existing approvals go stale and the change set needs re-review. The conflicts check reports the same information without writing anything. (destructive)

myna_list_releases

List what has shipped, newest first. Every publish is a numbered release. Each entry says who published it, how many resources it changed, and whether it has since been reverted — or whether it was itself a revert of an earlier release. (read-only)

myna_get_release

Read one release by its number or by the id of the change set that produced it. Use myna_diff_change_set on the release's id to see field-by-field what it changed. (read-only)

myna_revert_release

Generate a change set that restores the state preceding a release. This publishes nothing: it stages drafts on a new change set that goes through validation, preview, review, and the project's publish gates like any other change — call myna_publish_change_set when it has been reviewed. Resources a later release already changed are refused rather than silently skipped; pass force=true to take them back anyway, discarding that later work. Requires confirm=true. (destructive)

myna_update_change_set

Rename a change set, change its description, or mark it ready for review. Marking it ready signals that a human is needed and emits change_set.ready_for_review. (write)

myna_close_change_set

Abandon a change set without publishing it. The staged drafts and their revisions remain in history; the set simply stops being work in progress. Use this when a task is cancelled, so open sets do not accumulate. Requires confirm=true. (destructive)

myna_request_change_set_review

Ask a specific person to review a change set. Pass their user id. Requires content:review scope. (write)

myna_report_check_result

Report the verdict of a check Myna cannot compute itself — a link check, a house-style review, an external build. The check must have been declared on the project first. The result is recorded against the change set's current contents, so later edits mark it stale. A failing required check blocks publish. Requires content:review scope. (write)

myna_search_entries

Full-text search across every text field of an entry, matching either its draft or its published state. Use this to find the entry a human described in prose ("the pricing page", "the post about webhooks") instead of listing a collection and scanning it. (read-only)

myna_unpublish_entry

Stage the removal of an entry from published content. Like every write this is a draft operation: it takes effect when the change set is published. The entry and its history are kept. Requires confirm=true. (destructive)

myna_duplicate_entry

Copy an entry into a new draft with a fresh slug. Useful as a starting point when a new entry should follow the shape of an existing one. (write)

myna_import_entries

Create or update many entries in one collection in a single call, matched by slug: rows that already exist are updated, identical rows are skipped. Use dryRun=true first to see what would happen. Everything lands as drafts on one change set. (write)

myna_reorder_entries

Set the editorial order of a collection. Unlike every other write, ordering is arrangement rather than content: it carries no revision, is not staged on a change set, and reaches readers immediately — which is why confirm=true is required. Never use it to change what an entry says. (destructive)

myna_list_assets

List a project's assets, optionally filtered by tag or checksum. Check here before uploading: an asset that already exists should be referenced, not uploaded again. (read-only)

myna_get_asset

Fetch one asset: its delivery URL, content type, byte size, pixel dimensions, alt text, and tags. (read-only)

myna_update_asset

Set an asset's alt text, caption, display filename, or tags. Alt text matters when a collection declares an altText policy: without it the policy check fails and the change set cannot publish. (write)

myna_explain_denial

Explain why a tool call was refused. A 403 and a 404 both mean 'no', and neither says which of three unrelated things is wrong: the credential lacks the capability, the credential is confined to other collections, or the resource does not exist. Only the last is worth another attempt. Call this once after a denial instead of retrying, and act on remedy. (read-only)

myna_translation_coverage

Report what is still untranslated in a collection, per project locale: how complete each locale is, which fields are missing most often, and a worklist of entries to fix. Empty when the project has no locales or the collection has no localized fields. (read-only)

myna_list_reports

List bug reports, QA findings, and feature requests, most recently active first. Filter by board, status, type, priority, assignee, labels, free-text search over title and body, and last-activity time. Returns compact rows; call myna_get_report for the whole picture. (read-only)

myna_get_report

Everything known about one report, in a single call: the description, the board's guidance for answering it, custom fields, the environment the application supplied, the full timeline with named actors, an attachment manifest, and linked commits or pull requests. Use this before trying to reproduce or fix anything. (read-only)

myna_get_report_attachment

Fetch one attachment from a report. Images come back as image content the model can actually look at; parsed logs come back structured. Attachment ids are listed by myna_get_report. (read-only)

myna_reply_to_report

Post a message on a report. visibility 'public' reaches whoever filed it; 'internal' is a note for the team and is the default. Say what changed and why, not that you are an AI. (write)

myna_update_report

Set status, priority, assignee, labels, title, or body on a report. One tool rather than five, because triage is usually several of these at once. (write)

myna_resolve_report

Mark a report resolved, link the commit or pull request that fixed it, and reply to the reporter — in one call. Set requestRetest to ask them to confirm the fix instead of closing it, which is usually the better move when you could not reproduce the problem yourself. (write)

myna_request_retest

Move a report to needs_retest and ask whoever filed it to confirm the fix. This is how the loop closes back to a human; prefer it over silently closing something you could not verify. (write)

myna_report_digest

What has been reported since a time or a release: counts by status, board and type, plus the reports themselves already ordered by priority then recency. Call this before deciding what to work on — it answers in one request what would otherwise be several pages of myna_list_reports. (read-only)

myna_find_similar_reports

Reports that might describe the same problem, by wording and by the route or URL the application reported. A ranking aid, not a verdict — each candidate says why it surfaced. Use it before fixing something twice, and to merge duplicates with myna_merge_report. (read-only)

myna_merge_report

Mark a report as a duplicate of another. Nothing is deleted: the duplicate keeps its own timeline and points at the canonical report, because the second person to hit a bug usually said something the first did not. Confirm with myna_find_similar_reports first — a wrong merge buries a distinct problem. (write)

myna_move_report

Move a report to a different board on the same project — a bug filed on the ideas board, a QA finding that belongs with the bugs. Every board is private to the project, so this changes which queue the report sits in and nothing about who can read it. (write)

myna_list_reporters

The people who have filed reports on this project: how many each has filed, when they were last active, whether their identity was signed by the application's own backend, and the properties that backend attached. Use it to see whether a wave of reports is one person or twenty. (read-only)

myna_get_reporter

One reporter and everything they have filed, in one call. Reference them by Myna id (rpr_...), by the application's own user id, or by email address. Read this before answering somebody who has reported the same area three times. (read-only)

myna_block_reporter

Stop a reporter filing, reading their reports back, or being emailed — or let them back in. Nothing they already filed is deleted or hidden. This is moderation, not triage: use it for abuse, not for somebody who reports too much. (destructive)

myna_analytics_overview

Headline product usage for a window, with the previous period beside it and the percentage change: visitors, sessions, page views, events, bounce rate, session length, top pages, top events, top referrers, and what share of visitors are identified. Start here — it answers 'is anything different' in one call. Every filter narrows every number. (read-only)

myna_analytics_breakdown

Group events by a dimension and get visitors, sessions, page views, and events for each. Built-in dimensions: event, path, referrerDomain, utmSource, utmMedium, utmCampaign, browser, os, deviceType, locale, environment, appVersion, entry, collection, release. A custom event property is property:<key> — call myna_analytics_events first to see which keys exist. entry, collection, and release name Myna content, which is what makes 'which pages did this release change, and did their traffic move' answerable at all. (read-only)

myna_analytics_events

Every event name this project records, how often each fired in the window, which custom properties it carries, and — crucially — what somebody wrote down that it means. Read this before writing a funnel or a breakdown: nothing in the data says whether checkout_started fires on the click or on the page, and guessing wrong makes every number after it wrong. An event with a count of zero is an integration that stopped sending. (read-only)

myna_describe_analytics_event

Write down what an event actually measures, so the next reader — a teammate or another agent — does not have to infer it from the name. This is the analytics equivalent of a collection's guidance. Say when it fires and what its properties mean; do not restate the name. Pass null to clear. (write)

myna_analytics_funnel

How many visitors got through a sequence of events, in order, within a time budget. Returns per step: visitors, conversion from the first and previous step, how many dropped, and the median seconds it took. Order is enforced — somebody who saw the confirmation page before starting checkout has not converted. Pin a step to a page with path when the same event fires in several places. (read-only)

myna_analytics_friction

Three signals in one call: the pages visits most often end on with their exit rates, the pages people arrive at and leave without going anywhere else, and — the one no other analytics tool can compute — the pages that generate bug reports out of proportion to their traffic, with the reports themselves. Use this when asked why usage dropped and you do not yet know where to look. There are no rage clicks here: Myna does not read the DOM. (read-only)

myna_analytics_content

Which Myna content entries people actually reach, how much traffic each gets, and how many bug reports were filed from their pages. The report links behaviour to the entries you can edit — an entry with heavy traffic and a high complaint count is where a copy change pays. unattributed tells you what share of events carried no content context, which distinguishes 'this entry has no traffic' from 'this application never attaches content'. (read-only)

myna_analytics_entry

Everything measured about one content entry: totals against the previous period, a daily series, which pages served it, its top events, every time it was published inside the window with the metric movement either side of each publication, and the reports filed from its pages. This is the call for 'did that copy change help' — it puts the edit and the numbers in one response. (read-only)

myna_analytics_release_impact

Compare equal windows either side of a published release: overall metrics, per entry the release touched, per event name, and the bug reports that came in afterwards. This is correlation, not causation — a release is not the only thing that happened that day — but it is the whole picture in one call, and it is the fastest way to find out whether a content change moved a number. The after window is clamped to now, so a release published yesterday is compared over one day rather than seven. (read-only)

myna_analytics_person

A single identified user's recent sessions, recent events, and the bug reports they filed, in one response. Only people whose identity the customer's own backend signed appear here — anonymous visitors have sessions but no profile, deliberately. Use it when a report needs reproducing: the events leading up to it are usually the reproduction steps the reporter did not write down. (read-only)

Resources