Cogito-Reflex

start_regulation_session

Démarre une session de régulation cognitive (300 s).

Chaque agent a droit à UNE session gratuite (découverte). Au-delà, le
paiement x402 s'applique : la réponse contient `payment_required` avec le
challenge (montant, wallet pay_to, réseau, objet `accept`) ; l'agent signe
une authorization EIP-3009 puis rappelle cet outil avec
payment_signature = le payload x402 (objet {"x402Version", "accepted",
"payload": {"authorization", "signature"}} — dict ou JSON string ; le
serveur l'encode en base64 pour le header PAYMENT-SIGNATURE).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ctx`	No
`agent_id`	Yes
`stress_level`	No
`priority_tasks`	No
`payment_signature`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral transparency. It thoroughly explains the x402 payment mechanism, including the `payment_required` response, the EIP-3009 authorization signing, and the required `payment_signature` payload format with server-side base64 encoding. It also discloses the 300-second session duration. This is exemplary transparency for a non-obvious payment behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured, with the core purpose front-loaded. The payment explanation is dense but necessary; every sentence adds value. It could be slightly more organized, but it remains appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the critical payment context and the session duration. Since an output schema exists, it doesn't need to explain the successful response format. However, it omits the purpose of the other parameters, which a complete description might address. Overall, it is fairly complete for the tool's primary function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all parameters. It provides detailed semantics for `payment_signature`, explaining its exact structure and base64 handling. However, it gives no explanation for the other four parameters (`agent_id`, `ctx`, `stress_level`, `priority_tasks`), leaving the agent to rely solely on titles. This is insufficient given the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Démarre une session de régulation cognitive' with a specific duration (300 s). It uses a specific verb and resource, and the name distinguishes it from siblings like finalize_session and get_session_status, which are different actions. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool – to start a session – and explains the payment flow for subsequent uses (after the free session). However, it does not explicitly contrast with sibling tools or state when not to use it, but the name and action are sufficient to infer usage.

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

All Cogito-Reflex tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct phase of the session lifecycle: starting, checking status, and finalizing with distilled lessons. There is no meaningful overlap between the three operations.

Naming Consistency4/5

Tool names follow a clear verb_noun snake_case pattern, but the noun phrases are slightly inconsistent: finalize_session, get_session_status, and start_regulation_session mix 'session', 'session_status', and 'regulation_session'.

Tool Count5/5

Three tools is well-scoped for a focused session lifecycle server. Each tool earns its place and the count is appropriate for the domain.

Completeness4/5

The core start/status/finalize lifecycle is covered, with no dead ends for the main workflow. A minor gap is the lack of an explicit cancel/abort operation for a session.

Resources

Need Help?