MCP
Two revisions, one endpoint, and what a waiting call looks like on the wire.
One endpoint: https://mcp.sallyport.cloud/mcp. Two protocol revisions, each on its own handler.
Which revision you get
| Revision | Shape | How approval arrives |
|---|---|---|
| 2026-07-28 | Stateless. Discovery instead of initialize, no session header, no server stream | Tasks when the client declares the extension, otherwise a URL to open |
| 2025-11-25 | Session based | A held call with progress and a ceiling, then a URL and a call id |
The tool list
One tool per binding, with a description a person can read: the service, the credential by name, what runs at once and what waits. The list is marked private to the caller, because it differs per agent and a shared cache would show one tenant another tenant’s tools.
A call that needs a person
{
"resultType": "input_required",
"call_id": "call_01J…",
"approve_url": "https://my.sallyport.cloud/approve/call_01J…",
"expires_at": "…",
"poll_after_ms": 3000,
"expected_wait_ms": 60000,
"instruction": "A person is being asked about this call. Open the link or repeat this call with the same call_id."
}The instruction lives in the text content the model reads, not only in the structured field it may skip. Repeat the call with the same id and you continue the same operation rather than starting a second one.
Every stopping answer in this product carries a URL that a person can use to clear the obstacle in one press. That is a rule with a test behind it, not a convention.