Tool schema signature monitoring and drift handling

Verified 2026-09-05 · 55 claims · sources tier 1–2 · 1 disputed · 2 superseded

Also known as Allow signature change, listChanged, listFunctions, rug pull, schema signature, signature change, signature drift, tool signature, tools/list_changed, unsecure flag, x-mcp-header.

Webex computes a schema signature for each tool and continuously monitors it for changes 52. When a tool's current signature differs from the version an administrator previously approved, Webex flags the tool as possibly modified since the last review 29.

How signature monitoring works

Cisco does not publish the algorithm, the hash function, the field set, or the field ordering used to compute a Webex tool schema signature, nor the monitoring interval, nor where the signature is stored 28. WarmTransfer's reading of the sources is that the Webex tool signature can be inferred to cover at least the tool name, its description, its input schema, the required or optional status of fields, and validation constraints because the published scenario table treats a change to each of these as a signature change 30.

Cisco states that Webex automatically detects changes in server metadata, enablement state, and tool schema signatures and surfaces them in administrator views so that the administrator does not need to poll 16. The post-approval monitoring table lists 6 signals: tool signature change, server metadata change, enablement change, unusual usage patterns, user complaints, and server downtime, each with the mechanism that detects it 17. A server metadata change is defined as a developer edit to the description, the server URL, the authentication type, the publish data, or the submission status, and Cisco advises re-review on URL or authentication type changes 15.

Webex exposes a per-tool setting named Allow signature change that an administrator sets for each tool 13. Cisco recommends setting Allow signature change to Off for sensitive operations and regulated environments, noting the trade-off that users lose access until the administrator re-reviews 49. Conversely, Cisco describes Allow signature change set to On as acceptable for read-only tools and trusted publishers with a good track record, stating that it accepts the risk of unreviewed changes 50. Cisco's stated best practice is to default Allow signature change to Off for new or unfamiliar servers and to switch it On only after establishing trust with the publisher through multiple successful review cycles 48.

At runtime, when a tool's live signature differs from the stored signature and Allow signature change is Off, the tool is filtered out of listFunctions results and is not delivered to the client SDK 21. WarmTransfer's reading of the sources is that the endpoint named listFunctions through which drifted tools are filtered is a Webex construct and appears in none of the Model Context Protocol specification pages read in this tranche 14. When a tool's live signature differs from the stored signature and Allow signature change is On, the tool is still delivered to the client SDK and carries unsecure set to true so that client SDKs and agent user interfaces can surface a warning to end users 22. The client-visible drift flag is spelled unsecure, and the spelling insecure does not appear in the Webex documentation 51.

Signature change scenarios and risk ratings

Cisco lists 6 triggers for a full re-review: a signature change when the policy is Off, a major version bump, a reported security incident, a change in organisational security policy, a user report of unexpected behaviour, and more than 6 months since the last review 19. An administrator revokes approval by toggling the app to Blocked in Control Hub, which Cisco states takes immediate effect 20.

Protocol-level drift mechanisms and limitations

The Model Context Protocol specification revisions published as of the access date are 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28, with the latest alias resolving to 2026-07-28 41. In the field, the Tools page of the specification roughly doubled in extracted length between revision 2025-06-18 and revision 2026-07-28, from about 10,000 characters to about 21,000 46.

In the Model Context Protocol, the listChanged capability indicates whether the server will emit notifications when the list of available tools changes 37. The protocol's list changed notification method is notifications/tools/list_changed 36. In the 2025-06-18 revision, a server that declared the listChanged capability was advised that it SHOULD simply send a notification without delivery conditions 31. In the 2026-07-28 revision, a server that declared the listChanged capability SHOULD send the notification to clients that have opened a subscriptions/listen stream with toolsListChanged set to true 32. The 2026-07-28 message flow diagram shows the server answering a subscriptions listen request with a notification named notifications/subscriptions/acknowledged 3.

In the 2025-06-18 Tools page, the message flow diagram depicts the client re-issuing the tools list request after a list changed notification in the main flow with no optional fragment around it 2. This is disputed: the 2025-06-18 Tools page names the notification tools/list_changed inside its message flow diagram, while the prose of the same revision names it notifications/tools/list_changed 1. The 2026-07-28 Tools page message flow diagram wraps the subscription handshake, the list changed notification, and the client's re-issued tools list request in a single optional fragment labelled listChanged 4.

Neither the 2025-06-18 nor the 2026-07-28 revision states any obligation on a client that receives a tools list changed notification 40. WarmTransfer's reading of the sources is that a protocol-level listChanged notification cannot by itself reveal a tool whose schema changed without the server announcing it, because the specification makes the notification a SHOULD and imposes no client obligation 18. Furthermore, WarmTransfer's reading of the sources is that the Webex signature and approval mechanism goes beyond what the Model Context Protocol requires because the protocol defines only an optional announcement of tool list changes while Webex stores an approved signature, compares it at runtime, and withholds or flags the tool 53.

The Model Context Protocol security best practices page carries no section on tool schema change, tool poisoning, or rug pull attacks, and its attack sections are all authorization shaped 44. The 5 message flow diagrams on that security best practices page depict consent phishing, a skipped consent cookie, server-side request forgery to a cloud metadata endpoint, and script injection leading to arbitrary command execution, and none of them concerns tool schemas 5.

Protocol schema rules and constraints

• The set of tools a server returns MUST NOT vary per connection or as a side effect of other requests on the connection, although it MAY change over time 39.
• The tool set MAY vary by the authorization presented on the request, on the stated ground that credentials are per-request input rather than connection state 38.
• Servers SHOULD return tools in a deterministic order—meaning the same ordering across requests when the underlying set has not changed—citing reliable client caching and model prompt cache hit rates as reasons 34.
• Tool names SHOULD be between 1 and 128 characters in length inclusive 45.
• A tool's inputSchema and outputSchema default to JSON Schema 2020-12 when no schema field is present, and inputSchema MUST be a valid JSON Schema object and not null 42. WarmTransfer's reading of the sources is that because the JSON Schema dialect defaults when the schema field is absent, 2 tools with identical visible schemas may be validated under different dialects 43.
• For tools with no parameters, 2 valid forms are provided, and the specification recommends the form that sets additionalProperties to false because it explicitly accepts only empty objects 35.
• Schema properties MAY carry an x-mcp-header annotation that exposes parameter values as HTTP headers 47.
• For trust and safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers 33.

See also

• See also Agentic apps registration approval and identity badges.
• See also Model Context Protocol actions in Webex contact centre AI.
• See also Webex published MCP servers for external AI clients.
• See also The MCP subscriptions listen stream and notification delivery.
• See also Stateful tools in the Model Context Protocol.
• See also Webex Calling capabilities exposed through an agent interface.
• See also The combined Webex Suite MCP server.
• See also Webex Contact Center AI agent assist and virtual agents.
• See also Contact center transcription and redaction.
• See also Agent assist and real-time guidance.
• See also Virtual agents and conversational IVR design.
• See also Automated call summarization and wrap-up.
• See also AI quality management and auto scoring.
• See also Webex AI Agent Studio scripted and autonomous agents.
• See also Cisco per-model AI transparency technical notes.
• See also Supported languages and voices for Webex AI agents.
• See also Unified CCX Webex AI Agent integration.
• See also Third-party model and speech vendors behind Webex contact centre AI.
• See also Employment decision safeguards on automated agent scoring.
• See also The Webex App Hub as a marketplace.

Applicability

Across the claims in this article, the evidence covers Cisco Webex cloud deployment, verified as of 2026-09-05. Specific Model Context Protocol requirements apply across specification revisions 2025-06-18 and 2026-07-28 41​31​32.

What remains uncertain

The algorithm and field manifest behind the Webex tool schema signature are not covered by any claim in this article. What a client SDK does with unsecure by default is not covered by any claim in this article. The Webex listFunctions endpoint contract is not covered by any claim in this article. Stateful tools introduced in the 2026-07-28 revision are not covered by any claim in this article. The full details of the subscriptions listen stream introduced in 2026-07-28 are not covered by any claim in this article. Whether a future protocol revision addresses schema drift is not covered by any claim in this article. The deprecated features section new in the 2026-07-28 revision is not covered by any claim in this article. How a client decides a server is trusted for annotation purposes is not covered by any claim in this article.

WarmTransfer. (2026, September 5). Tool schema signature monitoring and drift handling. WarmTransfer. https://warmtransfer.net/knowledge/mcp-tool-signature-drift

@misc{warmtransfer-mcp-tool-signature-drift,
  title  = {Tool schema signature monitoring and drift handling},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/mcp-tool-signature-drift},
  note   = {Verified 2026-09-05}
}