eve could not assign a unique toolResultFrom identity for Atlassian tools

[jimdrury]

eve version

0.11.4

Node.js version

24

Where does the bug occur?

Local dev (eve dev)

Describe the bug

When an agent defines two or more OpenAPI connections against the same host (a common pattern for Atlassian Jira + Confluence, or multiple APIs on one domain), eve logs a warning at load time and marks the shared fallback identity as ambiguous. This makes toolResultFrom unreliable when passed the authored definition objects imported from connection modules.

Warning message

eve could not assign a unique toolResultFrom identity for "connection:https://virginmediao2.atlassian.net". 
Conflicting definitions: connection "confluence" from "connections/confluence.ts" and connection "jira"
from "connections/jira.ts". Multiple authored definitions share that fallback identity, so toolResultFrom
will not match through it. Use the original definition object loaded by eve so source-derived identity
can be used instead.

Steps to reproduce

Reproduction

1. Create two OpenAPI connections with the same baseUrl:

// agent/connections/jira.ts
export default defineOpenAPIConnection({
  spec: jiraSpec,
  baseUrl: "https://example.atlassian.net",
  // ...
});

// agent/connections/confluence.ts
export default defineOpenAPIConnection({
  spec: confluenceSpec,
  baseUrl: "https://example.atlassian.net",
  // ...
});

2. Start the agent (eve dev or eve build).

3. Observe the warning above during connection resolution.

Expected behavior

Expected behavior

One of:

• Multiple connections to the same host should be supported without warnings, or
• The fallback identity should incorporate something unique (connection slug/name, logical path, or sourceId) rather than URL alone, or
• The warning/docs should clearly state that URL-based fallback identity is intentionally one-per-host and show the recommended pattern for multi-connection setups.

Actual behavior

• Warning logged at startup for every additional connection sharing the host.
• toolResultFrom(event, importedConnection) does not match when using the module export directly (the common pattern shown in docs for hooks).
• Agent tool execution itself still works — connections are distinguished at runtime by qualified tool names (e.g. jira__getIssue, confluence__getPageById).

[ZhYGuoL]

Confirmed on main. Two connections that share a host collide on the fallback identity connection:<host>. registerDefinitionSource (packages/eve/src/public/tool-result-narrowing.ts:126) sees the second registration carry a different name, marks the key ambiguous, and warns at lines 130-137; toolResultFrom then returns undefined for that key (tool-result-narrowing.ts:200).

Repro: two defineOpenAPIConnection with the same baseUrl and different descriptions, registered the way resolveConnectionDefinition does, then narrowed through the imported objects:

eve could not assign a unique toolResultFrom identity for "connection:https://example.atlassian.net". Conflicting definitions: connection "jira" from "connections/jira.ts" and connection "confluence" from "connections/confluence.ts". Multiple authored definitions share that fallback identity, so toolResultFrom will not match through it. Use the original definition object loaded by eve so source-derived identity can be used instead.
AssertionError: expected "warn" to not be called at all, but actually been called 1 times

Root cause: the authoring-time fallback key was connection:<url> for both protocols (openapi.ts:122, mcp.ts:99), keyed on URL alone, so same-host definitions map to one identity. Authored tools already disambiguate by description (tool.ts:227); connections only by URL. The source-derived key (connection-source:<sourceId>) only reaches the object eve loaded, so a module export passed to toolResultFrom falls back to the colliding URL key.

Fix folds the connection description into the fallback identity via a shared connectionDefinitionKey(url, description) used by both define* factories and the resolver, so same-host connections with different descriptions get distinct identities while identical url+description stays genuinely ambiguous (warning preserved). It also aligns the OpenAPI key to baseUrl ?? "" so it matches the compiled url (normalize-connection.ts:62) when baseUrl is omitted, and widens toolResultFrom to accept OpenAPI connections, which the runtime already narrowed but the type rejected.

PR: #772