Unclassified

11 — MCP, ADK, SDK, APIs, and Developer Platform

Status: Canonical boundaries; publication states vary

Public MCP

services/mcp-connector/ owns the exact nineteen semantic tools:

  1. get_my_continuity
  2. get_active_context
  3. get_my_focus
  4. get_context
  5. get_changes
  6. get_related
  7. get_history
  8. get_commitments
  9. get_decisions
  10. get_permitted_memory
  11. get_relevant_knowledge
  12. ask_twin
  13. assign_twin
  14. get_prepared_work
  15. get_available_actions
  16. prepare_action
  17. get_action_plan
  18. approve_action
  19. store_in_spine

Any different public inventory is a stop-ship defect.

The tool contract is packaged in two ways:

  • IW-Spine-Network Plugin for plugin directories: MCP-backed app, focused
    sandboxed widgets, workflow skills and optional templates inside the AI host;
  • IW-Spine-Network MCP for MCP registries: remote server, optional MCP App
    widgets, meaningful text/JSON fallback and browser Workbench launch.

UI resources do not increase the nineteen-tool inventory.

ADK and agents

The ADK defines governed agent registration, context scope, tool scope, memory
scope, approval boundary, status, evidence, stopping rule, and escalation. Agents
do not access the canonical database directly and cannot self-promote output.

SDK responsibilities

Public SDKs should remain small and versioned:

  • authentication and tenant-aware API clients;
  • semantic Spine and Workbench contracts;
  • MCP client/server helpers;
  • capability and connector conformance helpers;
  • governed agent registration;
  • event envelopes;
  • canonical schema types.

Package names, public APIs, licensing, support, changelog, semantic versioning,
security policy, examples, and compatibility tests must be ready before public
publication.

API boundary

Gateway is the public control boundary. Product clients do not call provider
SDKs, storage, Nango, or internal MCPs directly. Public APIs use verified
identity, tenant scoping, versioned contracts, rate limits, structured errors,
audit correlation, and revocation.

Skills and plugins

A distributable skill includes:

  • complete SKILL.md;
  • triggers and intended user;
  • required context and evidence;
  • permitted and prohibited actions;
  • identity, tenant, Governance, and Hermes boundaries;
  • failure and escalation behavior;
  • examples, tests, owner, and version.

Plugins package capabilities; they do not create a second Platform or bypass
the public Spine Network contract. An embedded widget cannot inspect host DOM,
cookies or unrelated app credentials.

Publication state

Code-backed packages may be Implemented while still private. “Published” means a
versioned artifact is publicly retrievable, documented, install-tested, and
supported.