Neotoma

Overview Schema Source Related Servers Discussions Admin

sync_issues

Sync local Neotoma with a GitHub repo's issues. Pull leg: GitHub issues and their messages are pulled into local entities.

Instructions

Sync local Neotoma with a GitHub repo's issues. Pull leg: GitHub issues and their messages are pulled into local entities. Push leg: local public issues with no github_number are sanitized (PII stripped) and created on GitHub, then updated locally with the returned number/url. Target repo defaults to the server-configured repo (NEOTOMA_ISSUES_REPO); pass repo (owner/name) to mirror a different repo for one call without changing server config. The push leg is ON by default only for the configured default repo and OFF for any other repo unless push: true is passed. Pass commit: false for a dry run that reports what would be created, updated and pushed and writes nothing. Requires a GitHub token: NEOTOMA_ISSUES_GITHUB_TOKEN in the server environment (or gh auth login on the server host). Supports filtering by state, labels, and since date.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sync_issues"
  }
}

Input Schema

Name	Required	Description
`push`	No	Run the push leg (local public → GitHub). Default: true when `repo` is omitted or equals the configured default repo; false for any other `repo`. Pass true to opt in for another repo.
`repo`	No	GitHub repository to mirror, `owner/name`. Defaults to the server-configured repo (`NEOTOMA_ISSUES_REPO` / `issues.repo`). Must be the configured repo or be listed in the server's `NEOTOMA_ISSUES_ALLOWED_REPOS` (or `issues.allowed_repos`). A malformed or non-permitted value is rejected before any GitHub request or write.
`since`	No	Only sync issues updated after this ISO date.
`state`	No	Filter by issue state. Default: 'all'.
`commit`	No	When false, dry run: report what would be created, updated and pushed (`plan`) and write nothing locally or on GitHub. Default: true.
`labels`	No	Filter by labels.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.25.0Oct 12, 2026

addedInput schema / properties / commit

Added value: +{
+  "description": "When false, dry run: report what would be created, updated and pushed (`plan`) and write nothing locally or on GitHub. Default: true.",
+  "type": "boolean"
+}

changedInput schema / properties / push / description

Previous value: -"When false, skip the push leg (local public → GitHub). Default: true."New value: +"Run the push leg (local public → GitHub). Default: true when `repo` is omitted or equals the configured default repo; false for any other `repo`. Pass true to opt in for another repo."

addedInput schema / properties / repo

Added value: +{
+  "description": "GitHub repository to mirror, `owner/name`. Defaults to the server-configured repo (`NEOTOMA_ISSUES_REPO` / `issues.repo`). Must be the configured repo or be listed in the server's `NEOTOMA_ISSUES_ALLOWED_REPOS` (or `issues.allowed_repos`). A malformed or non-permitted value is rejected before any GitHub request or write.",
+  "pattern": "^[A-Za-z0-9](?:[A-Za-z0-9-]{0,37}[A-Za-z0-9])?/(?!\\.{1,2}$)[A-Za-z0-9._-]{1,100}$",
+  "type": "string"
+}

Addedv0.15.0May 31, 2026
Removedv0.14.0May 22, 2026

Changed1 schema field changedv0.13.0May 19, 2026

addedInput schema / properties / push

Added value: +{
+  "description": "When false, skip the push leg (local public → GitHub). Default: true.",
+  "type": "boolean"
+}

Addedv0.12.1May 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so excellently: it details both legs, PII sanitization on push, that dry run writes nothing, the default-repo push behavior, allowed-repo enforcement, and the required GitHub token. This is unusually rich behavioral disclosure for a sync operation.

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 purpose is front-loaded in the first sentence, and every subsequent sentence adds a distinct operational fact (legs, PII stripping, default repo behavior, dry run, token requirement). There is no filler, and the density is appropriate for the tool's complexity.

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?

There is no output schema or annotations, yet the description covers the full behavior an agent needs: what each leg does, defaults for push and repo, dry-run semantics, sanitization, and authentication requirements. Nothing essential for correct invocation 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 every parameter in detail, including the push/repo default logic. The description reinforces but does not meaningfully extend the schema's parameter semantics, matching the baseline of 3 for high-coverage schemas.

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 first sentence states a specific verb and resource ('Sync local Neotoma with a GitHub repo's issues') and immediately distinguishes the pull and push legs. It is clearly differentiated from sibling tools like submit_issue and add_issue_message, which handle individual issues rather than full repo synchronization.

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 conditional guidance: push is on by default for the configured repo and off for others, dry run is enabled via commit: false, and a repo override mirrors a different repo for one call. It does not explicitly name alternative sibling tools or state when not to use this tool, but the operational context is thorough.

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

Deploy Server