Skip to content

Add ExecPlan: translate tool schemas per backend (2.3.3)#69

Draft
leynos wants to merge 1 commit into
mainfrom
translate-tool-schemas-backend-ef5foq
Draft

Add ExecPlan: translate tool schemas per backend (2.3.3)#69
leynos wants to merge 1 commit into
mainfrom
translate-tool-schemas-backend-ef5foq

Conversation

@leynos

@leynos leynos commented Apr 10, 2026

Copy link
Copy Markdown
Owner

Summary

  • Introduces a new execution plan document for roadmap item 2.3.3: Translate tool schemas per backend.
  • Formalizes the plan to translate canonical MCP tool definitions into backend-specific tool schema shapes, with validation and hexagonal-boundary considerations.
  • Establishes phased work with clear gates, risks, and success criteria.

Changes

  • Added docs/execplans/2-3-3-translate-tool-schemas-per-backend.md containing the full ExecPlan:
    • Purpose, constraints, tolerances, risks, progress, surprises, decision log, outcomes.
    • Context on the current repository state and the proposed plan of work.
    • Plan of work detailing Stages A through G (lock contracts, tests, translation modules, orchestration wiring, adapters, coverage, and documentation gates).

Rationale

  • Bridges the gap between canonical MCP tool definitions discovered at runtime and the backend-specific tool schema formats consumed by each agent runtime.
  • Adheres to hexagonal architecture boundaries by keeping translation/validation logic in agent_backend (via ports) and leaving adapters and runtimes to handle backend specifics.
  • Sets a clear, test-driven pathway with stage gates to minimize risk and scope creep.

Plan of work (high level)

  • Stage A: Lock contracts and backend translation model (define ports, types, and initial profiles).
  • Stage B: Add red tests first (unit and behavioural) to describe expected translation/validation behavior.
  • Stage C: Implement pure translation and validation modules (core mapping and invariants).
  • Stage D: Wire orchestration to discovered tools and translated schemas (load tools, translate, attach to runtime requests).
  • Stage E: Implement adapter and fixture support (in-memory and PostgreSQL paths).
  • Stage F: Finish behavioural and regression coverage (happy/unhappy/edge cases).
  • Stage G: Documentation, roadmap updates, and final gates (update design/docs and mark 2.3.3 done upon gates).

Success criteria / observable outcomes

  • Unit tests (rstest) cover translation mapping and validation across backends.
  • Behaviour tests (rstest-bdd) verify backend receives translated tool schemas automatically.
  • In-memory and PostgreSQL-backed integration tests demonstrate end-to-end flow from discovery to translated schemas.
  • Documentation updates propagate to docs/corbusier-design.md, docs/users-guide.md, and docs/roadmap.md only after quality gates pass.
  • 2.3.3 is marked done in the roadmap after all gates pass.

Risks and mitigations

  • Tight coupling risk between translation logic and backend adapters; mitigated by explicit port boundaries and non-intrusive contract changes.
  • Potential growth of translation surface area; mitigated by staged approach and focusing on initial profiles.

Testing / gate plan

  • Gate through Makefile targets: make fmt, make check-fmt, make lint, make test, make markdownlint, make nixie, with pipefail and logging as required.
  • Ensure all tests pass and documentation is updated only after gates are cleared.

Impact on docs and users

  • Once implemented and gates pass, update docs/corbusier-design.md, docs/users-guide.md, and docs/roadmap.md to reflect the new backend-translation behavior and any profile-specific considerations.

◳ Generated by DevBoxer


ℹ️ Tag @devboxerhub to ask questions and address PR feedback

📎 Task: https://www.devboxer.com/task/678da699-ed9e-45c7-a9cd-d3254db4544a

Summary by Sourcery

Documentation:

  • Introduce docs/execplans/2-3-3-translate-tool-schemas-per-backend.md outlining the purpose, constraints, risks, and staged implementation plan for backend-specific MCP tool schema translation.

…er backend

Introduce a comprehensive execution plan document for roadmap item 2.3.3 that outlines the design, constraints, risks, progress, and staged plan for implementing schema translation from canonical MCP tool definitions to backend-specific formats. This new doc establishes the missing contract seam between tool discovery and backend runtime execution, including plans for translation profiles, validation strategies, testing, and orchestration integration to enable consistent tool schema supply across multiple backends.

Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
@coderabbitai

coderabbitai Bot commented Apr 10, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: a4d79033-8764-406b-8107-931f2f3baf68

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch translate-tool-schemas-backend-ef5foq

Comment @coderabbitai help to get the list of available commands and usage tips.

@sourcery-ai

sourcery-ai Bot commented Apr 10, 2026

Copy link
Copy Markdown
Contributor

Reviewer's Guide

Adds a new ExecPlan document for roadmap item 2.3.3 that defines how canonical MCP tool definitions will be translated and validated into backend-specific tool schemas, including staged implementation, constraints, risks, testing and documentation gates.

Sequence diagram for tool discovery, translation, and runtime execution

sequenceDiagram
  participant Orchestrator as AgentTurnOrchestratorService
  participant AvToolsPort as AvailableToolsPort
  participant ToolReg as ToolRegistryReadPort
  participant ProfileSel as BackendProfileSelector
  participant Translator as ToolTranslationService
  participant Validator as ToolValidationService
  participant RuntimePort as RuntimePort
  participant Runtime as AgentRuntimeAdapter

  Orchestrator->>AvToolsPort: list_available_tools(backend_id)
  AvToolsPort->>ToolReg: fetch_canonical_tools(backend_id)
  ToolReg-->>AvToolsPort: canonical_tools
  AvToolsPort-->>Orchestrator: canonical_tools

  Orchestrator->>ProfileSel: select_profile(backend_metadata)
  ProfileSel-->>Orchestrator: translation_profile

  loop for each canonical_tool
    Orchestrator->>Translator: translate_tool(canonical_tool, translation_profile)
    Translator-->>Orchestrator: translated_tool_schema
    Orchestrator->>Validator: validate_translation(canonical_tool, translated_tool_schema, translation_profile)
    Validator-->>Orchestrator: validation_result
    Orchestrator-->>Orchestrator: collect_translated_tool(translated_tool_schema)
  end

  Orchestrator->>RuntimePort: execute_turn(turn_execution_request_with_translated_tools)
  RuntimePort->>Runtime: execute_turn(turn_execution_request_with_translated_tools)
  Runtime-->>RuntimePort: turn_result
  RuntimePort-->>Orchestrator: turn_result
Loading

Class diagram for planned translation and runtime contracts

classDiagram
  class AgentTurnOrchestratorService {
    +execute_turn(conversation_id, prompt, backend_id) TurnResult
    -load_available_tools(backend_id) CanonicalToolList
    -build_turn_request(conversation_id, prompt, backend_id, translated_tools) TurnExecutionRequest
    -handle_translation_failure(error) OrchestrationError
  }

  class AvailableToolsPort {
    <<interface>>
    +list_available_tools(backend_id) CanonicalToolList
  }

  class ToolRegistryReadPort {
    <<interface>>
    +fetch_canonical_tools(backend_id) CanonicalToolList
  }

  class RuntimePort {
    <<interface>>
    +execute_turn(request) TurnResult
  }

  class ToolRouterPort {
    <<interface>>
    +route_tool_call(tool_call) ToolCallResult
  }

  class BackendProfileSelector {
    +select_profile(backend_metadata) TranslationProfile
  }

  class ToolTranslationService {
    +translate_tool(canonical_tool, profile) TranslatedToolSchema
  }

  class ToolValidationService {
    +validate_translation(canonical_tool, translated_tool, profile) ValidationResult
  }

  class TurnExecutionRequest {
    +conversation_id: Uuid
    +prompt: String
    +tool_calls: ToolCallList
    +available_tools: TranslatedToolSchemaList
  }

  class McpToolDefinition {
    +name: String
    +description: String
    +input_schema: JsonValue
    +output_schema: JsonValue
  }

  class TranslatedToolSchema {
    +backend_profile: TranslationProfile
    +name: String
    +description: String
    +schema_payload: JsonValue
  }

  class TranslationProfile {
    +id: String
    +backend_name: String
    +provider: String
  }

  class TranslationError {
    +kind: TranslationErrorKind
    +message: String
  }

  class ValidationResult {
    +is_valid: bool
    +errors: ValidationErrorList
  }

  class AgentRuntimeAdapter {
    <<interface>>
    +execute_turn(request) TurnResult
  }

  class InMemoryAgentRuntimeAdapter {
    +last_received_tools: TranslatedToolSchemaList
    +execute_turn(request) TurnResult
  }

  class PostgresBackedAgentRuntimeAdapter {
    +execute_turn(request) TurnResult
  }

  AgentTurnOrchestratorService --> AvailableToolsPort : uses
  AvailableToolsPort --> ToolRegistryReadPort : backed_by

  AgentTurnOrchestratorService --> BackendProfileSelector : uses
  AgentTurnOrchestratorService --> ToolTranslationService : uses
  AgentTurnOrchestratorService --> ToolValidationService : uses

  AgentTurnOrchestratorService --> RuntimePort : uses
  RuntimePort --> AgentRuntimeAdapter : implemented_by
  AgentRuntimeAdapter <|-- InMemoryAgentRuntimeAdapter
  AgentRuntimeAdapter <|-- PostgresBackedAgentRuntimeAdapter

  ToolRouterPort ..> McpToolDefinition : routes_calls_for

  McpToolDefinition --> TurnExecutionRequest : referenced_in
  TranslatedToolSchema --> TurnExecutionRequest : attached_as_available_tools

  BackendProfileSelector --> TranslationProfile : returns
  ToolTranslationService --> McpToolDefinition : input
  ToolTranslationService --> TranslatedToolSchema : output
  ToolValidationService --> ValidationResult : output

  TranslationError --> TranslationProfile : may_reference
Loading

File-Level Changes

Change Details Files
Introduce an execution plan document capturing the staged implementation strategy for translating canonical MCP tool schemas to backend-specific schemas.
  • Add a new ExecPlan markdown document describing purpose, scope, and overall success criteria for roadmap item 2.3.3.
  • Document architectural constraints, tolerances, risks, and mitigations around keeping translation logic inside agent_backend with hexagonal boundaries.
  • Describe current system context and identify the missing seam between discovered MCP tools and backend runtime requests.
  • Define a multi-stage plan (Stages A–G) covering contract design, red tests, translation/validation modules, orchestration wiring, adapter support, coverage, and documentation/roadmap updates.
  • Specify test and CI gate expectations and how documentation and roadmap status will be updated once quality gates pass.
docs/execplans/2-3-3-translate-tool-schemas-per-backend.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant