How to disable naming convention warnings?

[cxcorp]

The naming convention enforcement does not work for me. For example, when creating a function named GameApp_InitInstance_candidate through the MCP, I get back warnings:

"Function name 'GameApp_InitInstance_candidate' — main part 'GameApp_InitInstance_candidate' is not PascalCase. Expected: GameappInitinstanceCandidate"
"Function name 'GameApp_InitInstance_candidate' — main part 'GameApp_InitInstance_candidate' contains underscores. Use PascalCase after the module prefix."
"Function name 'GameApp_InitInstance_candidate' does not start with a recognized verb. First word 'Game' not in allowed list. Common verbs: Get, Set, Initialize, Process, Calculate, Find, Check, Handle"

The first part about the pascalcase miiiight be debatable, but the last one about the function not starting with a verb is very hard for me to understand. What is the recommended naming for such a case where we are trying name e.g. a vtable function name or other opaque loosely related prefixed function?

[bethington]

Two things that I think clear this up:

1. The warnings are advisory, not blocking. The function was actually renamed successfully — the response includes status: "success" alongside the warnings array. Anything in warnings is just a flag for review; it does not roll back the operation. So your GameApp_InitInstance_candidate rename did go through.

2. For module-prefix style names (vtable methods, opaque containers, etc.), use an UPPERCASE_ prefix followed by _. The validator recognizes this pattern (NamingConventions.MODULE_PREFIX = ^[A-Z]+_[A-Z].*) and strips the prefix before applying the PascalCase / verb-first checks to the remainder. So GAMEAPP_InitInstanceCandidate (uppercase module prefix, PascalCase main part starting with the verb Init) validates cleanly. GameApp_… mixes case in the prefix, which is why the stripper does not match and the underscore-bearing main part trips three rules at once.

There is currently no off-switch to silence the warnings entirely. If a flag (e.g. GHIDRA_MCP_SKIP_NAMING_WARNINGS=1) would be useful for your workflow, open an issue and I will wire it up — it is a small change.

[cxcorp]

Okay, thank you. I think a flag would be useful so that the agent doesn't need to spend tokens every time thinking about "This is only a warning and I can ignore it"

[bethington]

Closing the loop on this one — the toggle you asked about now exists. Three separate Ghidra Tool Options control the strictness, and each one downgrades the hard rejects/structural rewrites to advisory warnings when disabled:

Tool Option	Scope	Shipped in
Strict Function Name Enforcement	rename_function_by_address verb-tier rules	v5.7.0 (#171, @Hummer12007)
Strict Naming Enforcement	rename_data, rename_global_variable, set_global, the apply_data_type prefix/type guard	v5.7.2 (#188, @Hummer12007)
Same option ↑	create_struct, add_struct_field, modify_struct_field (auto Hungarian-prefix on field names is now also suppressed)	v5.9.1 (#202, @1ndahaus3)

Find them in Ghidra: Edit → Tool Options → GhidraMCP.

For your GameApp_InitInstance_candidate case specifically: with Strict Function Name Enforcement turned off, the warnings remain (they're useful for review) but no longer block — and they were already non-blocking, so the practical change for you is just that they're surfaced as advisory rather than as hard status: "rejected" for any callers built against the strict-default path.

[Serentty]

Does that mean there is still no flag to turn off warnings entirely? The concept of the warnings is very useful to me, but since they are not currently customizable, they are just wasting tokens when working on a project that already has an established naming convention. It would be useful to turn them off entirely, and/or to be able to control what style is expected in granular detail. The former seems easier than the latter.

[bethington]

@Serentty — your timing is good: v5.11.2 shipped today with exactly the two things you asked for.

1. Turn warnings off entirely — drop a .ghidra-mcp/conventions.json at your Ghidra project root with:

{
  "strict_mode": "off"
}

That collapses all naming validation to no-ops, so the worker never burns tokens reading or acting on a warning. Or set it per-call by passing strict_mode: "off" in the body of rename_function_by_address, set_global, rename_or_label, rename_global_variable, or apply_data_type.

2. Customize the style granularly — same file, five sections:

{
  "function_naming": {
    "min_length": 6,
    "verbs_add": ["Init", "Cleanup"],
    "verbs_remove": ["Process"],
    "verb_tier_overrides": { "Render": 1 },
    "weak_nouns_add": ["Widget"],
    "weak_nouns_remove": ["Data"]
  },
  "hungarian": {
    "auto_fix_struct_fields": false
  },
  "global_naming": {
    "require_g_prefix": false
  },
  "plate_comments": {
    "validate": true,
    "required_sections": ["Purpose", "Notes"],
    "min_first_line_words": 3
  }
}

Every section is optional — provide only the knobs you want to change; the rest fall back to the built-in defaults so you're not copy-pasting the full ruleset.

Full schema reference, three-layer precedence (Tool Option → project file → per-call), and a worked non-Hungarian C++ example are in docs/prompts/CUSTOMIZING_CONVENTIONS.md.

Defaults reproduce the pre-v5.11.2 behavior exactly, so existing setups don't change unless they opt in.

[cxcorp]

That's fantastic, thank you very much!