Contents

NAPT MCP Best Practices

How to prompt your AI assistant effectively when using NAPT tools

Prompt Patterns That Work

AI assistants call NAPT tools based on how you phrase your request. These prompt patterns consistently produce the best results.

1Be specific about environment

“Generate a BGP script”
“Use NAPT to generate a BGP fault-finding script for Cisco IOS-XR routers in the staging environment using Netmiko”

Why: The tool accepts vendor, framework, and environment parameters. Without them, NAPT uses defaults that may not match your setup.

2Chain tools naturally

(two separate requests)
“Search NAPT for OSPF templates, then show me the full script for the best match for a Cisco IOS-XE campus network”

Why: Claude can call napt_search_templates then napt_get_script in one turn, giving you a complete answer without back-and-forth.

3Use dry-run explicitly

“Run the BGP audit on my routers”
“Run the BGP audit on all edge routers in staging — dry-run mode only, don’t connect to any devices”

Why: napt_run_script defaults to dry_run=true, but being explicit ensures Claude passes it correctly and you stay safe.

4Ask for context before action

“Before running anything, what findings does NAPT have from the last 24 hours for the BGP domain?”

Why: napt_get_findings gives you situational awareness before you decide which script to run. Use it as triage before action.

5Combine NAPT with your own context

“I have a BGP session down between 10.1.1.1 and 10.1.1.2 on edge-rtr-01. Use NAPT to generate a diagnostic script for this specific peer on Cisco IOS-XR”

Why: Giving Claude the specific IP and device makes NAPT’s intent parser generate a script tailored to your exact situation, not a generic template.

6Parse intent before scripting

“Use NAPT to parse this change: add eBGP peering with AS 65001 at 203.0.113.1 on core-rtr-01, max-prefix 50000. Show me the risk assessment before generating anything.”

Why: napt_parse_intent returns risk level and pre-flight checks. Review them before asking Claude to generate the execution script.

7Pipeline status as morning routine

“Check NAPT for any pipeline failures in the last 12 hours and summarise the critical findings”

Why: napt_get_findings + napt_get_pipeline_status together give you an overnight NOC summary without opening any browser tabs.

Tool Combinations That Work Together

Combo 1 — Morning NOC Check

  1. 1napt_get_findings (critical, last 12 hours)
  2. 2napt_get_pipeline_status (last run of nightly pipelines)
  3. 3napt_get_compliance (production score)

Prompt

Give me the NAPT morning check: critical findings last 12 hours, pipeline status, and compliance score

Combo 2 — Incident Response Flow

  1. 1napt_get_findings (filter by device)
  2. 2napt_get_script (relevant diagnostic)
  3. 3napt_run_script (dry-run first)
  4. 4(if dry-run passes) napt_run_script (live)

Prompt

edge-rtr-01 is showing high CPU. Check NAPT findings for it, get the appropriate diagnostic script, and run it in dry-run mode

Combo 3 — Change Preparation

  1. 1napt_parse_intent (risk assessment)
  2. 2napt_search_templates (find relevant template)
  3. 3napt_get_script (full script)
  4. 4napt_trigger_pipeline (after review)

Prompt

I need to add a new VLAN 200 across the campus distribution layer. Use NAPT to assess the risk, find the right template, and prepare the change script

Combo 4 — Compliance Investigation

  1. 1napt_get_compliance (overall score + failing controls)
  2. 2napt_search_templates (find remediation template)
  3. 3napt_generate_script (generate targeted fix)

Prompt

My CIS compliance score dropped. Use NAPT to find what's failing and generate a script to fix the top 3 issues

Security Best Practices

1. Scope your MCP key permissions

Only enable the permissions your workflow needs:

  • Read only: Use for morning checks and query-only workflows
  • Read + Generate: Add when you want script generation
  • Read + Generate + Execute: Only when running scripts (use staging env)
  • All including Pipelines: Only for automated CI/CD scenarios
Never give a key more permissions than it needs.

2. Never paste your key in a prompt

“My NAPT key is napt_mcp_abc123... use it to...”
Configure the key in your MCP client config file (not in the chat)

The MCP client reads the key from the environment variable, never from the conversation. Claude never sees your key.

3. Rotate keys regularly

  • Go to /mcp/keys → Regenerate
  • Update all MCP client configs with the new key
  • Old key is immediately invalidated
  • All past calls remain logged under the old key ID for audit

4. Use separate keys per environment

Create one key for your AI assistant (read + generate). Create a separate key for your CI/CD automation (execute + pipelines). This limits blast radius if a key is compromised.

5. Review the call log

/mcp/keys shows last used timestamp and source IP. If you see unexpected calls, regenerate immediately. All MCP calls are logged in napt_mcp_calls for audit.

6. Never allow production execute without MFA

Even with execute permission, NAPT requires a confirmation step for production changes. This cannot be bypassed via MCP.

What MCP Cannot Do

Be clear about MCP limitations so engineers don’t over-trust it.

MCP cannot modify live network devices without dry-run first

Every napt_run_script call defaults to dry_run=true. Live execution requires explicit dry_run=false AND execute permission.

MCP cannot access devices directly

NAPT MCP calls the NAPT API. NAPT talks to devices. Your AI assistant never has a direct SSH connection to anything.

MCP cannot see your device credentials

Credentials are stored in NAPT Secrets Vault and never returned via MCP.

MCP calls are rate-limited

Free: 100 MCP calls/day. Paid: 1,000/day. Enterprise: unlimited. Tool calls that hit the rate limit return a 429 with retry-after header.

MCP cannot run scripts larger than 30 seconds via the API

Long-running scripts should be triggered as pipelines (napt_trigger_pipeline) which run asynchronously and return a run_id for status polling.

Example Conversations

Example 1 — Generating a script in Cursor IDE

YouUse NAPT to write me a Python script that checks all BGP neighbors on our Juniper JunOS edge routers and flags any that have been up for less than an hour
Claude calls napt_generate_script with intent, vendor=juniper, framework=netmiko
Claude
NAPT generated bgp_uptime_checker.py. Here's what it does: - Connects to each JunOS device in your inventory via Netmiko - Runs 'show bgp neighbor summary' and parses with TextFSM - Flags neighbors with uptime < 3600 seconds - Outputs a rich table with device, peer IP, uptime, and state
bash
pip install netmiko ntc-templates rich
python bgp_uptime_checker.py --inventory devices.csv --dry-run
Here’s the full script: [script content]

Example 2 — Morning NOC check in Claude Desktop

YouGood morning — give me the NAPT overnight summary
Claude calls napt_get_findings(hours=8, severity='critical') then napt_get_pipeline_status() then napt_get_compliance()
Claude
Good morning. Here's your NAPT overnight summary: Findings (last 8 hours): - 2 critical: Interface flap on edge-rtr-02 (3 times, 02:14–02:18 IST) BGP session IDLE on pe-03 to peer 203.0.113.5 Pipelines: - Nightly compliance: ✓ Completed 02:00 IST (7/7 stages passed) - BGP audit: ✗ Failed 04:00 IST (stage 3: ssh timeout on core-rtr-01) Compliance: - CIS: 84% (↓2% from yesterday — 3 new SSH cipher warnings) - NIST: 77% (unchanged) Recommended first action: Check the BGP session to 203.0.113.5 on pe-03. Want me to use NAPT to generate a diagnostic script for that specific peer?

Example 3 — Incident response in Claude Desktop

Youpe-03 BGP to 203.0.113.5 is down. Help me investigate.
Claude calls napt_get_findings(device='pe-03', hours=24) then napt_get_script('bgp_fault') then napt_run_script in dry-run
Claude
From NAPT findings on pe-03 in the last 24 hours: - BGP session 203.0.113.5 went IDLE at 03:47 IST - Hold timer expired (reset reason from previous run) - This peer was also down briefly at 23:12 IST yesterday (recovered in 4 min) I've fetched the BGP Fault Finder script and run it in dry-run mode against pe-03. Dry-run passed — SSH reachable, inventory valid. Ready to run live? I'll execute napt_run_script targeting pe-03 only, dry_run=false. This will SSH to pe-03 and collect BGP state. Confirm?
YouYes, run it.
Claude calls napt_run_script(script_slug='bgp_fault', device='pe-03', dry_run=false)
Claude
Script ran in 12.4 seconds. Results from pe-03: - Peer 203.0.113.5 (AS 174): IDLE — Hold Timer Expired - Last reset: 3h 52m ago - Uptime before reset: 142 days - Reset count (7d): 4 resets (pattern: every ~4 hours recently) - Prefix count before reset: 24,182 This looks like a periodic hold-timer issue — 4 resets every ~4h suggests a flapping upstream. Want me to search NAPT for a BGP graceful-shutdown script to drain this peer safely while you investigate?

Sample Prompt Templates

Download these ready-to-use prompt templates as Markdown files. Fill in the placeholders and paste them into Claude, Cursor, or any MCP client to get consistent results.

Morning NOC Check

Overnight findings, pipeline status, and compliance summary.

Incident Response

Triage a device, fetch a diagnostic, and run a safe dry-run.

Change Preparation

Risk-assess a change, find a template, and prepare the script.

Script Generation

Generate a tailored script with explicit vendor and framework.