isWebMCP

Cisco · Support discovery and Product Information API · Proposed scenario

Make public support discovery easier to maintain

An illustrative pilot for a Cisco digital-experience team: review a public product-support finder, improve supported interface gaps, and attach source evidence to its release. No Cisco deployment has been inspected or evaluated.

Documented by the company

What the official sources establish

  • Cisco documents a REST/JSON Product Information API with lookups by product identifier and serial number; returned fields include a product-support-page URL.

    Cisco Support APIs: Product Information ↗

  • Cisco Support APIs require bearer tokens obtained using application credentials. That authenticated API is distinct from a public page and is not accessible through our unauthenticated scanner.

    Cisco Support APIs: Authentication ↗

Our proposed workflow—not a deployed integration

  • A proposed owner is the product-support web team, with an API/security reviewer. They choose one already-public, non-sensitive product-discovery page and a fixed URL that can be measured consistently across releases.
  • Save a source baseline, triage only findings supported by collected HTML, and adapt the accessible-controls recipe where relevant. A separate search-tool experiment could wrap an owner-controlled search function; it must not expose API credentials or customer serial-number queries.
  • After the team approves and deploys its own changes, run the same public URL and input context again. Attach the compatible source comparison to the release ticket. Existing Cisco APIs remain the execution layer; isWebMCP does not replace them.

What isWebMCP can provide now

  • Bounded public-source collection, a saved findings inventory, supported starter recipes, and local CLI comparison of complete compatible reports. The remote MCP interface can explain recipes and compare supplied summaries.
  • Imported tool-contract review can flag declared interface issues in a sanitized proposed search contract; it does not verify Cisco permissions, live API responses, or successful searches.

What needs development or agreement

  • Authenticated support workflows, private-network execution, credential delegation, and browser task verification are not provided. A Cisco-specific search adapter and any browser WebMCP compatibility require owner engineering and separate tests.

Proposed pilot · Not performed

A bounded way to test the hypothesis

Proposed two-week, owner-consented pilot: one public reference page, one web engineer, one security reviewer, and two approved releases. No network configuration, support-case creation, or customer data.

Deliverables to produce

  • A baseline, a reviewed remediation patch, an after-report, and a decision log that separates confirmed source changes from untested runtime hypotheses.

Measures to collect—not results

  • Proposed acceptance: both releases produce complete, comparable reports; every prioritized finding receives a fix, documented exception, or reproducible false-positive report.
  • Record setup time and reviewer minutes per finding. Proceed only if the owner identifies at least one useful, non-duplicative release decision; no agent-success or cost-saving result is assumed.

Stop or decline if…

  • Stop if the useful journey requires login, serial numbers, sensitive source content, weakened access controls, or an authenticated API call from isWebMCP.

Risks, constraints and unanswered questions

  • Rendered search behavior may be absent from fetched HTML. Existing accessibility or API tooling may already address the findings; duplication is a reason not to expand the pilot.

Source and date ledger

Research reviewed 2026-09-05. Dates describe the source, not a company trial. An unavailable publication date is left unknown.