Repository navigation
.NET: Align tool names for built in providers between c# and python #6398
Description
Having the same tool names simplifies building UX, since it means we can use a common set of names when formatting tool output. This is especially important when using e.g. a dotnet console with a python service or vice versa.
- BackgroundAgents
- FileMemory
- FileAccess
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
[-]Align tool names for built in providers between c# and python[/-][+]Python: Align tool names for built in providers between c# and python[/+][-]Python: Align tool names for built in providers between c# and python[/-][+].NET: Align tool names for built in providers between c# and python[/+]cschanhniem commentedon Jun 18, 2026
Tool name alignment between C# and Python is more than a UX concern — its a governance boundary. When agents running in different runtimes (a .NET orchestrator dispatching to a Python tool server, or vice versa) use different names for the same function, the orchestrator cant enforce consistent tool-use policies.
Two patterns worth building into this alignment:
Canonical tool names as capability identifiers: If
FileAccessis the canonical name for file operations, then policy rules (e.g., "agent-reviewer may useFileAccessbut notShellCommand") become portable across runtimes. The tool name becomes the policy key, and the runtime-specific mapping is an implementation detail.Tool schema versioning: As tool signatures evolve, having a shared naming convention makes it possible to detect "stale agent" scenarios — an agent compiled against
FileAccess.v1shouldnt silently invokeFileAccess.v2which may have different security properties.This aligns directly with what were building in AGENTOWNERS (https://github.com/cschanhniem/AGENTOWNERS) — a CODEOWNERS-style policy file where maintainers define per-agent tool access rules. Canonical tool names make those policy rules runtime-agnostic, so the same
AGENTOWNERS.ymlworks whether the host is .NET or Python.