Set the active pricing model. RESTRICTED to operator.
Requires a valid proof (Schnorr-signed kind-27235 event) proving the caller holds the operator's nsec.
| Name | Required | Description | Default |
|---|---|---|---|
| dpop_token | No | ||
| model_json | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the auth requirement (operator with proof) but does not explain behavioral traits such as whether the operation is destructive or what happens to the existing model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with distinct purpose: stating the action and the authorization requirement. No wasted words, front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and auth requirement but omits details on parameter values, error conditions, or the output schema. Given it is a mutation tool, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description does not explain model_json format or content, nor does it mention dpop_token. It adds little value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the active pricing model' with a specific verb and resource. It mentions restriction to operator, which differentiates it from read-only tools like optionality_get_pricing_model, but does not explicitly distinguish from optionality_reset_pricing_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool is restricted to operators and requires a Schnorr-signed proof, which provides context for when it can be used. However, it lacks guidance on when not to use it or when to consider alternatives like reset_pricing_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
There is substantial overlap and confusion between multiple sets of tools. For example, `optionality_get_operator_onboarding_status` and `optionality_get_patron_onboarding_status` serve different identities but have a similar purpose that could be confusing. More critically, there are generic-named tools like `optionality_receive_credentials` and `optionality_receive_npub_proof` that both drain a relay mailbox in a very similar way, distinguished primarily by the type of token they return. The presence of both `optionality_session_status` and `optionality_service_status` is a major point of ambiguity, as both seem to check the health and configuration of the operator.
The naming convention is highly consistent, using a snake_case, verb_noun pattern (e.g., `list_journal`, `delete_journal`). The prefix `optionality_` is applied to all tools. The verb 'get' and 'list' are used predictably. Minor point deduction for a few outliers like `optionality_deal_scenario` and `optionality_judge_trade` which are domain-specific verbs that don't perfectly fit the CRUD pattern but are still clear in context.
With 71 tools, this server is severely over-staffed. This indicates poor separation of concerns, likely bundling multiple distinct domains or services into a single surface. A tool count this high dramatically increases cognitive load and API surface area, making it difficult for an agent to find the correct tool.
The tool surface covers an enormous amount of functionality, including imaginative ownership-proof flows via Nostr DMs. However, the `check_balance`/`purchase_credits` flow appears incomplete without a `refund_credits` tool for operator support scenarios. While the server has a `restore_credits` tool, it requires authentication. Overall, the surface is individually creative but organizationally incoherent.