set-token

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

No annotations are provided, but the description fully compensates by disclosing key behavioral traits: the token is held in memory only, not persisted to disk, and lost on process restart. It also explains that the tool is rejected over HTTP transport for security reasons (preventing remote hijacking), which is significant 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 three sentences, each carrying distinct information: purpose, usage condition, in-memory persistence, and transport restriction. It is front-loaded with the main action and adds essential caveats without redundancy.

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?

Considering the tool's simplicity (one parameter, no output schema), the description is remarkably complete. It covers when to use it, how it behaves (in-memory, lost on restart), and a critical security constraint (stdio-only), leaving no obvious gaps 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 100% for the single 'token' parameter, so the schema already documents its meaning. The tool description adds no further parameter-level semantics beyond what the schema states, but it also doesn't need to given the simple, self-explanatory parameter.

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 tool's function: setting or replacing the syntx.ai bearer token used by the server at runtime. It names the specific resource (syntx.ai bearer token) and action (set or replace), and the scope (used by server at runtime) distinguishes it from any sibling tool.

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 gives explicit when-to-use guidance: 'Call this before any authenticated operation if SYNTX_TOKEN was not configured.' It also provides a clear alternative for HTTP transport (configure via the SYNTX_TOKEN env variable) and states the tool is stdio-only, preventing misuse over HTTP.

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