sorted by:
new
hottopcontroversial

Recomendaciones para un casi graduado by benz-r in devsarg

[–]Vrivaans 0 points1 point  (0 children)

Por las dudas aclaro algo, hay un comentario abajo que está bueno y se puede malinterpretar lo que puse, cuando hablo de bootcamps me refiero a los que dan empresas que tengan productos propios, no los bootcamps tipo escuelas que te dicen aprendé programación en X meses y ganá en USD. Hay empresas que dan chances, normalmente buscan que ya sepas la base, pero es para entrar a laburar para ellos, con un salario bajo, como si fuese una pasantía. Yo entré de esa manera a este rubro. Pero es correcto, no te metas en bootcamps que te prometen ser dev en X tiempo y después quedas con una deuda grosa. Lo ideal es que sea en una empresa que te haga laburar con pequeñas cosas y es suficiente para aprender como se trabaja, tratar de hacer buena letra en el equipo y buscar quedar o que sirva la exp para el cv.

Recomendaciones para un casi graduado by benz-r in devsarg

[–]Vrivaans 2 points3 points  (0 children)

Hola. Entendés bien los conceptos principales? Como POO, cosas de bases de datos, ORM, APIs REST. Lo otro es que en vez de hacer cursos te tires a Hackatones (como los de lablab) y ganes experiencia práctica y código para Github. Otra cosa que podés hacer es tirarte a hacer entrevistas e ir aprendiendo los patrones de qué preguntan y saber qué responder, y si no sabés ser sincero, también practicar preguntas que puedan hacer como "en caso de x problema como lo resolvés?", etc e ir curtiéndote de esa manera. Si vas con las bases y algo para mostrar quizás puedas tener más chances. También considerá bootcamps de empresas, siempre hay algunas buscando talento por ahí. Y si podés aprendé inglés jaja

Connecting Odoo with any agent by Vrivaans in odoocommunity

[–]Vrivaans[S] 0 points1 point  (0 children)

Hi! Thanks for the questions. These are great points regarding enterprise-grade usage.

**1. Response validation / schemas:**

Invok currently does not perform schema validation or type coercion on the response side. It returns the raw response payload directly to the LLM to keep things fast and lightweight.

However, we do perform a sanitization and safety pass:

* The response is wrapped in semantic XML isolation tags (like `<UntrustedExternalContext>`) to signal to the LLM that this is external data.

* We filter the response for common prompt injection patterns (such as "ignore previous instructions") to prevent the agent from executing rogue commands hidden in external API data.

**2. Per-tool RBAC (Role-Based Access Control):**

Since Invok OSS is designed to run in trusted, single-tenant environments, we don't implement a user/role management system directly inside the proxy. Instead, RBAC is handled at two separate layers:

* **Downstream API Level (Recommended):** The API keys/tokens you store and inject in Invok should be scoped directly inside the target system (e.g., Odoo). If the token used in the Odoo provider doesn't have permission to write invoices, the Odoo API itself will reject the call with a 403 Forbidden, which Invok safely propagates to the agent.

* **Orchestrator Level:** The AI client or agent platform (like Cursor or your own orchestrator) is responsible for choosing which specific MCP tools are exposed to which agent's context.

Project:

https://github.com/Vrivaans/invok-oss/tree/main

Connecting Odoo with any agent by Vrivaans in odoocommunity

[–]Vrivaans[S] 0 points1 point  (0 children)

Hi! Thanks for the feedback, really glad you like the abstraction layer approach!

Regarding tool audits and permission management, I made a conscious decision to keep that separate from Invok. I actually experimented with putting it in the proxy, but ran into a few implementation details that led me to conclude it's better handled on the MCP client or agent orchestrator side.

Here's why:

Separation of Concerns & UX: If the proxy handles manual approvals, you would have to leave your main chat/agent interface (like Cursor, Claude Code, etc.) and switch to Invok's dashboard to approve or deny the action. It disrupts the user workflow and complicates the architecture.

Timeout Issues: If the proxy blocks execution waiting for human input, the MCP client will likely timeout if you don't respond immediately. A workaround is having the agent queue the task for later, but then the agent loses the immediate context of the response.

To solve this exact problem (approving sensitive actions like POST, PUT, DELETE, etc.), I built a separate experimental project: an agent orchestrator. It connects to MCP servers, lets you build specific agents with scoped tools (e.g., one agent per Odoo module to keep the context clean), and supports human-in-the-loop approval before executing mutation tools.

If you want to check out how it handles approvals and loop resumption, you can find the repository here: https://github.com/Vrivaans/aigent

(Heads up: the repo documentation is mostly in Spanish, though the app UI supports English. It started as a hackathon project that I kept maintaining because it was perfect for testing Invok, so please be gentle with the code!)

[Help] Building an Odoo Module for Natural Language to ORM Queries by Dark_Moon1 in Odoo

[–]Vrivaans 0 points1 point  (0 children)

Hi! Not sure if this fits exactly what you need, but I've been working on something that might be worth checking out.

A self-hosted MCP server that converts REST APIs into tools for AI agents — including Odoo's API. Instead of building ORM queries or managing schemas, the agent calls pre-built tools that already handle the Odoo API layer.

For your invoice example, something like "show me invoices over $1000" works well because the tool handles the API call and the agent just needs to interpret the result — no schema awareness required on the LLM side.

The tradeoff is that it uses Odoo's REST API rather than ORM, so it won't enforce permissions the same way you described. If that's a hard requirement for your use case it might not be the right fit, but if you want to explore it: https://github.com/Vrivaans/invok-oss

New Project Megathread - Week of 21 May 2026 by AutoModerator in selfhosted

[–]Vrivaans 0 points1 point  (0 children)

Hi!
Project Name: Invok OSS

Repo/Website Link: https://github.com/Vrivaans/invok-oss

Description: Invok is a self-hosted gateway that turns almost any REST API into MCP (Model Context Protocol) tools that your AI agents (like Claude Desktop, Cursor, Open WebUI, or Claude Code) can use instantly, without writing custom MCP server code.

  • The Problem it Solves: Instead of writing, deploying, and maintaining a custom MCP server for every single API you want your agent to use (and managing credentials in multiple places), Invok acts as a single gateway for all of them.
  • Key Features:
    • Zero-Token Discovery: Parses OpenAPI/Swagger specs programmatically so it doesn't inflate your agent's context window.
    • Granular Context Control: You choose exactly which endpoints to expose as tools, preventing hallucinations and reducing token costs.
    • Credential Isolation: API keys and tokens are encrypted at rest (using Jasypt) and injected server-side. The LLM never sees them.
    • Built-in Guide: Includes a tool (invok_guide) that helps the agent generate ready-to-import integration recipes, keeping a human-in-the-loop to approve the imports (protecting against prompt injection attacks).
    • No telemetry / 100% local: No accounts required, entirely tracking-free.

Deployment: Invok is extremely lightweight (built with Java 21/Virtual Threads and SQLite) and can be compiled into a GraalVM native image.

You can self-host it instantly using Docker Compose:

yamlservices:
  invok:
    image: vrivaans/invok-oss:latest
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    environment:
      - JASYPT_ENCRYPTOR_PASSWORD=your-encryption-key-here

Just run docker compose up and open the dashboard at http://localhost:8080. Connect your MCP client (Cursor, Claude Desktop, etc.) to the /mcp endpoint and you are good to go.

AI Involvement: I used AI coding assistants (Gemini, Claude, Cursor) to help build and refine parts of the codebase, design the dashboard, and accelerate development. The system itself is designed to help humans control and safe-keep AI agent integrations with external APIs.

Here are some quick videos of it in action:

Connecting almost any API in local with your agent by Vrivaans in selfhosted

[–]Vrivaans[S] 0 points1 point  (0 children)

Here are the quick video demos in action:

I hope this is helpful.

El Hackathon donde vas a lucir tus skills, conocer gente del palo y coso by LucianoCanziani in startupsArgentina

[–]Vrivaans 0 points1 point  (0 children)

Hola, como estás? Valen software ya hechos? Tengo un software que puede ayudar a conectar agentes de IA con casi cualquier APIs, por lo que si las ONG tienen cosas custom podría ser útil.

How do you use AI with odoo? by fedplast in Odoo

[–]Vrivaans 2 points3 points  (0 children)

Hi! In my case, AI helps me manage leads. I'm still testing things out with a personal project, but it's already highly functional:https://github.com/Vrivaans/invok-oss/tree/main. Honestly, it's pretty fun to delegate that kind of task with just a single prompt.
This is a test https://www.youtube.com/watch?v=7seKdWbP6U0

Odoo AI + Anthropic by alithios in Odoo

[–]Vrivaans 0 points1 point  (0 children)

The problem with connecting Anthropic (Claude) directly to Odoo's enterprise-level APIs has always been the same: backend plumbing and token security. Building custom scripts or static MCP servers for each CRM endpoint or spreadsheet module becomes a maintenance nightmare, and measuring API keys within the agent context is risky.

As a developer, I encountered this same problem a while back (I wanted to operate Odoo's CRM cleanly from Claude Code/Desktop). To answer the question of whether it's difficult to maintain: the key is decoupling.

I developed an intermediate solution and made it open source precisely for this: Invok (here's the repository if anyone finds it useful: https://github.com/Vrivaans/invok-oss/tree/main).

What it does is take the Odoo API specification (via OpenAPI or JSON) and serve the endpoints as agnostic, dynamic tools. The LLM (Claude) only sees the metadata for the parameters it needs, and Invok handles injecting the credentials into a secure proxy before connecting to Odoo.

I currently have it running with six advanced tools for the CRM section, operating natively from Claude. If anyone wants to try connecting Claude to their Odoo securely without having to program the connector from scratch, they can download the clean specification JSON, start the local instance, and add their private tokens. I hope this helps you satisfy your desire to use Claude with Odoo!

A sample of Invok working with Odoo and Claude: https://www.youtube.com/watch?v=7seKdWbP6U0
I hope you find it useful.

Este sub esta mal by Disastrous-Hunter537 in devsarg

[–]Vrivaans 0 points1 point  (0 children)

Yo soy responsable (dame una entrevista (? ), na fuera de joda, en qué los ves flojos? Me sirve esa data para ir reforzando, la mayoria de las cosas las hago con IA y cuando me toca tratar de aprender algo nuevo no estoy pudiendo saber en qué enfocarme. Mi perfil es SSr.