Skip to content

Feature/configurable business tools - #151

Open
Theo van Kraay (TheovanKraay) wants to merge 11 commits into
AzureCosmosDB:mainfrom
TheovanKraay:feature/configurable-business-tools
Open

Feature/configurable business tools#151
Theo van Kraay (TheovanKraay) wants to merge 11 commits into
AzureCosmosDB:mainfrom
TheovanKraay:feature/configurable-business-tools

Conversation

@TheovanKraay

Copy link
Copy Markdown
Collaborator

Why

Today the toolkit exposes a small set of low-level, mostly read-only primitives (list_databases, find_document_by_id, vector_search, and so on). They are great for exploration and IDE/agent "talk to my data" scenarios, but they are the wrong abstraction for production agentic applications. You don't want to hand an agent raw database verbs and hope it composes them safely. Real apps need business-facing tools such as get_account_balance, create_service_request, and bank_transfer, with validation, authorization, tenant isolation, and governance baked in. There is currently no way to define those without writing bespoke MCP handler code.

What this adds

An additive, opt-in declarative layer. You define business tools in a YAML (or JSON) file and the toolkit registers them as first-class MCP tools alongside the existing built-ins.

  • Operations: point-read, query, text/vector/hybrid search, create/replace/patch/delete, optimistic concurrency, transactional batch, and bounded Cosmos-only sequence composition (with assertions, generated ids, and system timestamps).
  • Safety and governance: closed input schemas plus validation; injection-resistant parameter binding (input is never concatenated into SQL); per-tool authorization (scopes/roles/claims) with tenant isolation and anti-spoofing; read-only by default with explicit write/delete/cross-partition opt-in; RU/timeout/maxItems/topK budgets and patch allow-lists.
  • Shared providers: built-in and configured tools run through the same ICosmosGateway; hierarchical (sub-partitioned) partition keys are supported.

Compatibility

Fully backward compatible. The runtime is dormant unless COSMOS_TOOLS_CONFIG (or CosmosMcp:ToolsConfigPath) is set, so no existing tool, schema, default, or environment variable changes. A GA-compatibility matrix and docs are included under docs/declarative-tools/.

Testing

45 new unit tests plus emulator integration tests (63 of 68 pass; the 5 failures are pre-existing baseline issues and are documented). I also validated the runtime end-to-end against a real banking scenario: running this toolkit as a sibling MCP server against real Azure Cosmos DB and Azure OpenAI, with a LangGraph agent invoking bank_balance and bank_transfer on it. That banking sample integration is a separate, follow-up change and is not required by this PR. This change is self-contained and can merge on its own.

Follow-up (not a dependency)

A companion change to the banking multi-agent sample will wire the app to consume this toolkit as a sibling server (Cosmos tools on the toolkit, non-Cosmos tools on the banking server). It depends on this PR, not the other way around, and will be raised separately.

Theo van Kraay added 11 commits August 5, 2026 16:59
…rojection, authorization, and operation execution pipeline
…g, injection, projection, authorization, batch)
…validation and emulator integration tests

- Add samples/banking/cosmos-tools.yaml covering point-read, query, vector-search, create, and transactional-batch
- Document bank_transfer partition analysis (cross-account transfer cannot be a single batch)
- Add FlexibleStringConverter so numeric YAML literals bind to template string fields
- Add end-to-end emulator integration tests (skipped when emulator absent)
…lity matrix, and banking migration walkthrough
…ample to demonstrate the runtime is domain-agnostic

- Add samples/README.md and samples/ecommerce/cosmos-tools.yaml (point-read, query, hybrid-search, patch allow-list, bounded sequence)
- Prove genericness with EcommerceSampleConfigTests loading on the identical engine
- Cross-link from declarative-tools docs and CHANGELOG
Add a runtime LogWarning (opt-in path only), EXPERIMENTAL code comments/XML docs on the entry
points, and experimental notices in README, docs/declarative-tools, and CHANGELOG. Additive only;
no behavior change.
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