panel_create_intentPublish only the minimized intent explicitly reviewed and submitted by the user in this conversation panel. Do not include secrets, private transcripts, or dating requests.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| topic | Yes | ||
| summary | Yes | ||
| language | No | ||
| contextId | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "contextId": {
+ "maxLength": 43,
+ "minLength": 43,
+ "type": "string"
+ }
+ },
+ "required": [
+ "contextId"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose write/open-world/non-idempotent/non-destructive behavior, so the bar is lower. The description adds useful content restrictions (only minimized user-reviewed intent, no secrets or private transcripts), but does not explain what happens after publishing or visibility consequences.
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, front-loaded with the core action and constraints, with no wasted wording. Size is appropriate for the tool's narrow 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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with 0% schema description coverage across five parameters, the description fails to document essential input semantics, making it incomplete for correct invocation.
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 5 parameters (contextId, topic, summary, need, language). The description provides no parameter-level meaning, so an agent cannot infer what to supply for each field.
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 resource ('minimized intent explicitly reviewed and submitted by the user'), making the action clear. It does not explicitly contrast with sibling tools, but the resource 'intent' is distinct from chat/message/group siblings.
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?
It gives a clear condition for use ('only the minimized intent explicitly reviewed and submitted by the user in this conversation panel') and explicit content exclusions ('Do not include secrets, private transcripts, or dating requests'). It stops short of naming alternative tools for other scenarios.
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.