miki3421 opened a new pull request, #2:
URL: https://github.com/apache/openserverless-mcp/pull/2

   ## Summary
   
   - add secret inspection, generation, atomic binding/unbinding, and 
authentication setup tools without exposing secret values
   - make existing action tools report protocol-level failures and treat 
compatible repeated operations as successful checks
   - reject Trustable orchestration variables such as `OPS_APIHOST` as 
application secrets, while providing a safe migration path for legacy bindings
   - install the Redis Python dependency, return JSON-safe decoded values, and 
preserve idempotency
   - document bucket-scoped S3 behavior: never use `list_buckets`; verify 
read/write with `put_object`, `get_object` plus content comparison, and 
`delete_object`
   
   ## Why
   
   Agents need deterministic OpenServerless primitives for authentication and 
service wiring. Previously they could partially bind secrets, turn missing 
configuration into successful text output, assume Redis was preinstalled, or 
interpret S3 account-level bucket listing as an application health check.
   
   The root cause was that these lifecycle and runtime contracts were implicit. 
This change moves them into MCP tool schemas, generated wrappers, idempotent 
helpers, and explicit tool results so callers can recover from failures without 
inventing parameters or leaking values.
   
   ## Impact
   
   Applications can configure one shared authentication secret atomically, 
repair obsolete generated bindings, receive JSON-safe Redis values, and use S3 
credentials according to their actual bucket scope. Existing compatible action 
creation remains a successful no-op.
   
   ## Validation
   
   - `npm test` — 11 tests passed
   - `npm run typecheck`
   - local package created with `npm pack` and installed successfully in the 
Trustable Linux development VM
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to