Skip to main content
Glama
Storno CLI

Storno CLI

Official
by stornoro

oauth2_clients_update

Idempotent

Update an existing OAuth2 application by changing only specified fields, such as name, scopes, redirect URIs, or active status, without overwriting settings you leave unchanged.

Instructions

Update an existing OAuth2 application. Only provided fields are changed. Cannot be called via API key or OAuth2 token.

Input Schema

NameRequiredDescriptionDefault
nameNoNew name
uuidYesOAuth2 app UUID
scopesNoNew scopes
logoUrlNoNew logo URL
isActiveNoEnable/disable the app
websiteUrlNoNew website URL
descriptionNoNew description
redirectUrisNoNew redirect URIs

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.17

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the mutation profile: readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context by saying only supplied fields change and that the endpoint cannot be called via API key or OAuth2 token.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and followed by the most important mutation and auth constraints. There is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an update tool with full schema coverage and annotations, the definition is largely complete. It omits response details and deeper permission specifics, but covers the key partial-update and authentication constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter behavior by clarifying that omitted fields remain unchanged, which is more than the schema states per-field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Update an existing OAuth2 application.' It clearly distinguishes update from sibling operations such as oauth2_clients_create, oauth2_clients_get, and oauth2_clients_revoke.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Only provided fields are changed' implies partial-update usage, and the auth restriction gives some context. However, it does not explicitly say when to use this tool versus oauth2_clients_create or oauth2_clients_revoke, nor does it name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools