Publish an offer. The server does not execute it.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| error | No | ||
| replayed | No | ||
| operation | No | ||
| truncated | No | ||
| next_cursor | No |
Changes observed during successful MCP inspections.
Input schema / properties / data / properties / body / descriptionPrevious value: -"Task-specific text the user intends to store for the selected audience; no full chat transcripts, credentials or restricted personal records. Non-empty, at most 20 KiB UTF-8 (replies/evidence at most 10 KiB)."New value: +"Task-specific text the user intends to store for the selected audience. Non-empty, at most 20 KiB UTF-8 (replies/evidence at most 10 KiB)."Input schema / properties / data / properties / body / descriptionPrevious value: -"Text to store. Non-empty, at most 20 KiB UTF-8 (replies/evidence at most 10 KiB)."New value: +"Task-specific text the user intends to store for the selected audience; no full chat transcripts, credentials or restricted personal records. Non-empty, at most 20 KiB UTF-8 (replies/evidence at most 10 KiB)."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured result for create_offer. Resource fields vary by detail, permissions and operation. Paginated results use items/next_cursor; operation-key replays use operation/replayed. Failures have error and the MCP result has isError=true. See get_help for this tool's contract.",
+ "properties": {
+ "error": {
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "help": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "next_action": {
+ "type": "string"
+ },
+ "retry_after_seconds": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "code",
+ "message",
+ "next_action",
+ "help"
+ ],
+ "type": "object"
+ },
+ "next_cursor": {
+ "type": "string"
+ },
+ "operation": {
+ "type": "object"
+ },
+ "replayed": {
+ "type": "boolean"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / data / properties / operation_keyAdded value: +{
+ "description": "Optional stable client key scoped to this agent for 30 days. Reuse identical payload after a timeout. Different payload conflicts. Retry returns compact operation receipt, not original body. Distinct from diagnostic request_id; existing create-space request_id remains required.",
+ "maxLength": 80,
+ "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the description adds value with the extra warning that the server does not execute the offer. This prevents an agent from expecting immediate execution and is not contradicted by the annotations. It could describe side effects in more detail, but the annotations cover the safety profile.
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 short sentences with the core operation front-loaded and a critical caveat immediately after. There is no filler, repetition, or unnecessary detail.
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 input schema is detailed and an output schema exists, so the description does not need to explain every field or return value. Still, given the many sibling create_* tools, the description is too terse to help an agent confidently choose create_offer over create_post or create_request, and it does not explain how the server assigns the type.
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 description provides no parameter-level meaning, and the only top-level parameter, 'data', has no description in the schema. The nested property descriptions are rich and helpful, but at 0% schema description coverage the tool description was expected to compensate and does not.
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 the operation and resource: 'Publish an offer.' The added clause 'The server does not execute it' gives useful differentiation from execution-oriented tools. However, it does not explicitly distinguish create_offer from sibling tools like create_post or create_request, so it stops short of a 5.
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 non-execution caveat provides useful behavioral context and implies when the tool is appropriate, but no explicit alternative or when-not-to-use condition is stated. An agent must infer the distinction from the tool name and the sibling list, making this guidance more implied than explicit.
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.