dpyc-oracle

Update Operator

update_operator

Update an existing Operator's registry entry.

Used when an Operator moves to a new MCP endpoint, changes its display name, or needs to correct a registration. Called by an Authority when its owner approves the operator's update request; the request must be signed with that Authority's key.

Input Schema

Name	Required	Description
`service_url`	No	New MCP endpoint URL (leave empty to keep current).
`display_name`	No	New display name (leave empty to keep current).
`operator_npub`	Yes	Nostr npub of the Operator to update.
`authority_npub`	Yes	npub of the requesting Authority (must be a registered authority or prime_authority).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026
- removedInput schema / properties / authority_npub / default
```
Removed value: -""
```
- changedInput schema / required
```
Previous value: -[
-  "operator_npub"
-]New value: +[
+  "operator_npub",
+  "authority_npub"
+]
```

Changed4 schema fields changedAug 30, 2026

addedInput schema / properties / authority_npub / description

Added value: +"npub of the requesting Authority (must be a\nregistered authority or prime_authority)."

addedInput schema / properties / display_name / description

Added value: +"New display name (leave empty to keep current)."

addedInput schema / properties / operator_npub / description
```
Added value: +"Nostr npub of the Operator to update."
```

addedInput schema / properties / service_url / description

Added value: +"New MCP endpoint URL (leave empty to keep current)."

First observedAug 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the approval workflow (owner approves) and the authorization requirement ('the request must be signed with that Authority's key'). It omits failure behavior and whether unlisted fields are preserved, though the schema covers the latter.

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, then when-to-use, then the authorization constraint. No filler and nothing buried.

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

Completeness5/5

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

Output schema exists so return values need not be explained. Purpose, trigger conditions, and the signing/approval requirement are all present, which is everything an agent needs to invoke this mutation correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters are already documented, including 'leave empty to keep current'. The description's mention of endpoint and display-name changes loosely maps to those fields but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

Purpose4/5

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

States a specific verb+resource: 'Update an existing Operator's registry entry.' The word 'existing' implicitly separates it from register_operator and deregister_operator, but it never names those siblings directly. An agent can still tell what it does at a glance.

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

Usage Guidelines4/5

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

Gives clear trigger scenarios ('moves to a new MCP endpoint, changes its display name, or needs to correct a registration') and states the calling context. It does not explicitly exclude alternatives like register_operator/deregister_operator, so it stops short of full routing guidance.

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

All dpyc-oracle tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.