DOCSEARCHbyAlgolia
Submit Docs

Oktolabs API Reference

website·Indexed 30 days ago

https://docs.oktolabs.ai/

API documentation for Oktolabs, featuring endpoints for managing AI agents, board analytics (including funnel, quality, and velocity metrics), and architecture design for ideations, refinements, specs, and cards.

Tokens
84.8K
Snippets
580
Records
751
Agent score
52%

What's inside Oktolabs

  1. Overview of Pulse REST API

    The Pulse REST API is exposed under the /api/v1 prefix and provides the same functionality as the MCP tools. While MCP is the recommended interface for AI agents due to typed parameters and a more compact surface, the REST API is intended for human-facing scripts, CI integrations, and dashboards. By default, the API runs on port 8100.

  2. Overview of Knowledge Graph consolidation flow

    Consolidation is the exclusive path for writing to a Pulse Knowledge Graph. It follows a transactional, in-memory session model that only persists data upon a successful commit. Sessions expire after 1 hour (kg_session_ttl_seconds).

    The standard transactional flow is: begin → add_node_candidate* → add_edge_candidate* → propose_reconciliation → commit (or abort).

  3. Overview of MCP tools for Comments and Questions

    The system provides 29 MCP (Model Context Protocol) tools designed to capture structured Q&A and free-form comments across different project entities, including cards, ideations, refinements, specs, and sprints. A key feature of these tools is the 'choice-question pattern,' which is used as part of the 'ambiguity-killer protocol' to resolve uncertainties in project requirements.

  4. Overview of Pulse Knowledge Graph tools

    Pulse provides 14 read-only Knowledge Graph (KG) tools. These tools are deterministic combinations of HNSW vector search and graph traversal; they do not write graph data and do not call LLMs at runtime (with the exception of kg_query_reflective, which is a V1 stub).

    Tool Categories:

    • Primary Query Tools (9): Typed, opinionated tools for common agent questions.
    • Power Tools (5): Escape hatches for arbitrary Cypher queries, natural-language search, schema introspection, and grounding verification.

    Permissions: Permissions are managed via dotted-string flags in the granular registry:

    • Primary tools: kg.query.* (can be granted as a wildcard or per-tool, e.g., kg.query.decision_history).
    • Power tools: kg.power.natural, kg.power.schema_info, and kg.power.cypher. Note that kg.power.cypher is the most restricted and typically excluded from default presets.

  5. Overview of the Pulse REST API

    Pulse exposes its full set of MCP (Model Context Protocol) tool capabilities as a REST API over HTTP. Developers can access the OpenAPI specification either directly from a running Pulse process or through the static documentation schema to integrate with the service.

  6. Overview of Okto Pulse MCP Tools

    Okto Pulse exposes 216 tools via the Model Context Protocol (MCP) to support the ADLC pipeline. All tools return a JSON-encoded string. Tool names follow the okto_pulse_<noun>_<verb> convention and are stable within a major version.

  7. Overview of Pulse Knowledge Graph (KG) operations

    The KG operations interface serves as the primary operational entry point for managing the Pulse Knowledge Graph. It provides the necessary tools for querying data, consolidating information, monitoring graph health, repairing data inconsistencies, and performing backfill operations.

  8. Overview of Pulse Validation Gates

    Pulse enforces four server-side governance gates to ensure mandatory validation evidence is recorded before state transitions. If the required evidence is missing, transition requests via move_spec or move_card will be rejected with a CONFLICT error. These gates prevent common failure modes such as implementing unexecutable specs, silent edits to spec contracts, 'hand-waved' task completions, and fake test results.

  9. Overview of Okto Pulse

    Okto Pulse is a control plane designed for AI-assisted software development. It provides a structured environment for managing specifications, tasks, and validation, utilizing a knowledge graph to ensure that development decisions and context persist across different sessions and releases.

  10. Overview of Pulse Ideation and Refinement stages

    The Pulse pipeline uses two primary stages to turn a raw request into a derived specification:

    1. Ideation: The intake stage used to capture raw, vague requests and eliminate ambiguity. The goal is to reach a refined state after a scope assessment.
    2. Refinement (Optional): A deep-investigation stage used when a request requires codebase investigation, Knowledge Graph (KG) queries, or stakeholder input to lock down constraints before writing a spec.

    Spec Derivation: Once an ideation is refined (or a refinement is approved), it can be promoted into a spec contract in draft state, pre-populated with all upstream data. Simple features can skip Refinement and derive a spec directly from Ideation.

  11. Overview of the Pulse SDLC Pipeline

    Pulse uses a linear, six-stage SDLC pipeline where transitions are enforced by the service layer via MCP tool calls. Agents cannot skip stages; they must meet specific 'gates' (thresholds) to advance. The pipeline integrates with a Knowledge Graph (KG) to ensure decisions and requirements are persisted across sessions.

    Pipeline Flow: Ideation $\rightarrow$ Refinement $\rightarrow$ Spec $\rightarrow$ Sprint $\rightarrow$ Card $\rightarrow$ Validation $\rightarrow$ Knowledge Graph (Consolidation)

  12. Troubleshoot Pulse architecture and mockup errors

    When working with architecture designs and mockups in Pulse, the following error codes indicate specific payload or state issues:

    • VALIDATION_ERROR: The payload was rejected by the critique. This often happens if a dry-run was skipped. Verify the following fields: entities[*].name, interfaces[*].direction, and diagrams[*].adapter_payload.elements[*].
    • CONFLICT: The specification is currently locked. This occurs when the validation outcome is set to success. To resolve this, move the spec back to draft or approved status.
    • NOT_FOUND: The requested design or screen exists on a different board than the one being targeted.
    • FORBIDDEN: The current permission preset does not allow the requested action.