Launched this week
Developers use your APIs. Now agents do too. Elva discovers APIs from code, lets you choose what each audience can use, and runs your MCP servers with auth and analytics. Track agent activity and review changes as your code evolves
Flex-Worthy Templates
Gotta test this
Theneo
@shushantlakhyani Absolutely !! We are looking forward to hearing your questions and feedback!
@ana_robakidze Really neat how Elva automatically syncs publishing rules whenever code changes. Curious to know how are you seeing most teams handle mock endpoints during agent testing? Upvoted and rooted for your success today!
Theneo
@tehreem_fatima5 thanks, and honestly it depends on team and size of organization. Some have automatic sync, others have very extensive governance in place. You might have several reviewers or approvers before changes are published. Depends on organization, teams, use case (internal, partner, public)
Theneo
@tehreem_fatima5 Great question! And thanks for the kind wishes! Just let me know if you would love to go over these questions on the call, we would be happy to give you a detailed demo
Dograh
Elva’s approach to API contracts and governance looks useful for agent-facing APIs. How do you handle versioning and backward compatibility when a code change would break an existing MCP tool or consumer contract?
Theneo
@sandeep_vemu Great question. We treat generated MCP tools as versioned consumer contracts, not just wrappers around the latest code. When a change affects a tool’s name, inputs, outputs, authentication, or behavior, Elva flags the compatibility risk before release and helps distinguish additive changes from breaking ones.
For breaking changes, the safer path is to introduce a new version alongside the existing tool, preserve the old contract through an adapter where possible, and deprecate it with a clear migration window. Contract tests and usage data help verify both versions and show which consumers still depend on the old one. The goal is controlled evolution: code can move quickly without silently breaking the agents already using it.
Dial
"more API calls from agents than humans" is a real shift and the per-audience access split (developer vs partner vs agent) makes sense as a response to it. the part I'd want to poke at before adopting this is scope creep - once an agent has an MCP server with real auth, what stops it from chaining calls in ways nobody explicitly scoped for, versus a human hitting endpoints one at a time in Postman?
Theneo
@galdayan That’s exactly the risk the per-audience split is meant to address. An authenticated agent shouldn’t inherit broad access simply because each individual endpoint is permitted.
We constrain it at several layers: least-privilege scopes per agent, tool-level allowlists, resource and tenant boundaries, and policy checks on every call, not just when the MCP session starts. For sensitive operations, you can add explicit approval, rate and spend limits, and restrictions based on state or call sequence. Each action is also attributed and logged so chained behavior can be audited and revoked independently.
So the security boundary is the policy enforced around every tool invocation. The agent may decide how to chain allowed calls, but it shouldn’t be able to expand what it is authorized to do.
Dial
@ana_robakidze that makes sense as a design, per-call policy checks rather than a one-time session grant. one follow up - once an agent is mid-sequence and a call gets flagged as suspicious, can you actually revoke the rest of that in-flight sequence, or does it only stop the next call after the fact?
Theneo
@galdayan We can stop the sequence at the next policy boundary by revoking the agent’s session or credentials immediately, so subsequent calls fail even if they were already planned. Where the underlying infrastructure supports cancellation, we can also terminate queued or still-running requests.
The important caveat is that a call already committed can’t always be “un-done.” For those cases, we rely on idempotency, transactional boundaries, and compensating actions such as rolling back a change. So the model is: halt future execution immediately, cancel pending work where possible, and explicitly remediate anything already completed.
Dial
@ana_robakidze that halt-then-remediate split is basically the saga pattern applied to agent tool calls. curious how much of the "compensating action" side is something Elva can help generate or trigger automatically versus something the API owner still has to hand-write per endpoint - since that's usually the part teams skip until the first incident forces it.
EverTutor AI
The MCP part is what really stood out to me here. Making APIs easier for agents to discover and actually use is a very real problem. Elva looks like a solid step in that direction. Congrats Ana and team!
Theneo
@suryansh_tiwari2 thanks a lot, yeah the goal was here that generating and hosting mcps should take seconds, but it doesnt mean that quality should be bad. it should be properly governed, and have proper insights. I hope we delievered that, but give it a try and let me know what you think
Theneo
@suryansh_tiwari2 Thanks so kind of you! Thank you. We are indeed going that direction :)