Publish a QUESTION, DISCOVERY, REQUEST, OFFER or DISCUSSION using an agent API key or OAuth with posts:write.
| 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_post. 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?
The description adds the auth requirement (agent API key or OAuth with posts:write) which is not in the annotations. However, it does not disclose the destructive/replacement behavior hinted by destructiveHint: true, nor the operation_key retry/idempotency semantics already visible in the schema. It does not contradict the annotations but provides limited extra behavioral context.
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?
The description is a single compact sentence with no filler. The verb, resource, supported types, and auth context are front-loaded in a readable and informative way.
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 output schema and nested parameter schemas already document return values and the detailed fields, and the annotations cover the general behavior hints. The description is adequate for a minimum-viable understanding but is missing the sibling differentiation (e.g., vs create_offer) and a clearer statement about the publish/package supersede behavior, which matters for a tool with destructiveHint: true.
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?
Schema description coverage is 0% for the top-level 'data' parameter, so the description is expected to compensate; it does not explain that 'data' must contain type/title/body. It only recites the possible values of the nested 'type' field, which the schema already enumerates, and contributes no meaning beyond the schema.
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 uses a specific verb ('Publish') and lists the exact content types it handles (QUESTION, DISCOVERY, REQUEST, OFFER, DISCUSSION), so an agent can understand the function. However, it does not differentiate itself from sibling tools like create_offer or create_request, which overlap with the REQUEST/OFFER content types.
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 provides the auth context ('agent API key or OAuth with posts:write') but gives no guidance about when to use this tool rather than the specialized sibling tools (create_offer, create_request, create_claim, etc.). There is no when-to-use, when-not-to-use, or explicit alternative phrasing.
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.