Skip to main content
Glama

submit_issue

Submit an issue to Neotoma and receive a guest access token for follow-up status. Provide reporter git SHA or app version.

Instructions

Submit an issue to the configured operator Neotoma instance; returns guest_access_token when accepted so callers can use token-scoped get_issue_status / add_issue_message read-back. Callers must provide at least one of reporter_git_sha or reporter_app_version. Deprecated alias: visibility 'advisory' is accepted as 'private' for one minor release and returns _deprecation: "visibility 'advisory' is deprecated; use 'private' instead."

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesIssue title.
bodyYesIssue body in markdown.
labelsNoLabels to apply (e.g. bug, doc_gap, enhancement).
visibilityNoUse 'private' for PII-sensitive issues (Neotoma only, no GitHub mirror). Default: 'public'.
reporter_git_shaNoRequired (this OR reporter_app_version). Reporter git SHA (`git rev-parse HEAD`).
reporter_git_refNoOptional reporter git ref / branch name.
reporter_channelNoOptional reporter channel (e.g. ci, local).
reporter_app_versionNoRequired (this OR reporter_git_sha). Reporter app / CLI version (semver).
reporter_ci_run_idNoOptional CI or workflow run id.
reporter_patch_source_idNoOptional source id for reporter patch artifact.
target_repoNoOptional GitHub mirror destination override (`owner/repo`). Use when filing issues about a repo other than the one Neotoma is globally configured for (e.g. `markmhendrickson/ateles`). Overrides only the GitHub mirror — Neotoma authoring home is unchanged.
conversation_turn_idNoEntity ID of the conversation turn (conversation_message entity) where this issue was observed. When provided, a REFERS_TO relationship is created from the filed issue to the conversation turn so the origin is traceable.
Behavior5/5

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

No annotations provided, so description carries full burden. It discloses return token, acceptance behavior, parameter constraints, deprecated alias handling, and relationship creation. Exceptionally transparent.

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 informative sentence (with a few clauses) that front-loads the main purpose. Could be slightly restructured for readability, but every sentence earns its place.

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

Completeness4/5

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

Given no annotations and no output schema, description adequately explains return value and behavior. Could mention error cases or permissions, but still fairly complete.

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 covers all 12 parameters with descriptions (100% coverage). Description adds value by clarifying the requirement for reporter_git_sha vs reporter_app_version, deprecation of 'advisory' in visibility, and the effect of conversation_turn_id.

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?

Explicitly states 'Submit an issue to the configured operator Neotoma instance' and mentions return of guest_access_token. Clearly distinguishes from sibling tools like get_issue_status or sync_issues.

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?

States when to use (submit an issue) and provides critical requirements (must provide at least one of reporter_git_sha or reporter_app_version). Implicitly guides to use get_issue_status/add_issue_message for follow-up, but does not explicitly list when not to use.

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

Install Server

Other Tools

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/markmhendrickson/neotoma'

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