SPINE / Agent instructions
Check a Spine connection
Distinguish missing tools, incomplete sign-in, ambiguous bases and refused document access.
Documentation checked:
No tools are available
The skill and the MCP connection are separate components. A local skill cannot supply missing server tools. A repository plugin is not automatically installed in every cloud or mobile client.
Guide the user through the documented path for their client: Codex, Claude or Gemini. Do not run installation commands or change client configuration without authorization for that action.
Tools request authorization
Ask the user to complete the client’s Spine sign-in flow with their own account. Never ask them to paste passwords or access tokens into the conversation. The connection’s allowed bases and current membership constrain access; installing a package grants neither membership nor document permission.
The new target endpoint is https://app.spine-kb.com/mcp. The user receives the usable endpoint during onboarding. These instructions do not confirm that a deployment is currently reachable.
Several bases are possible
Use spine_bases when needed. A full private document URL, explicit base ID or unambiguous task determines the target. If none does, ask the user which base they intend. Never use an unrelated browser’s active-base cookie as MCP authority, and never silently pick the first or last-used base.
Once the target is resolved, call spine_bootstrap and read its returned personal document. Repeat bootstrap when switching bases and reread when the returned revision changes. See the agent entry for the complete sequence.
A base or document is refused
Report the refusal without probing other bases for the same document or retrying the operation in another base. An explicit unavailable base stays refused. Do not change grants, add users to groups or create a public token as a workaround.
Public token links remain a separate access context. Do not substitute the user’s private identity access for /s/ reading.
A result is unclear
Check the tool’s domain result and the server’s current spine_guide contract. Do not treat transport success alone as a successful domain operation. For an uncertain write outcome, follow the server’s idempotency rules rather than issuing a fresh unrelated write.
The guides document supported platform setup and the intended server contract. Real installation, OAuth, skill delivery and client behaviour on the new deployment remain separate verification work.