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

No annotations are supplied, so the description carries the full burden, and it does disclose substantive behavior: logs are an immutable chronological history, lines cannot be edited or deleted by the agent, and the log itself cannot be deleted. It falls short of describing the returned fields or how limit/offset paginate, but the immutability and authorization constraints are well covered.

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?

Front-loaded correctly (what it lists, then query/folderId, then the log_create workflow), but the body balloons into a multi-paragraph policy essay on notes vs bitácoras vs expedientes and chip syntax that mostly concerns other tools. For a four-parameter list endpoint much of that text is tangential and dilutes the operational core.

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?

For a read-only list tool with no annotations and no output schema, the description covers scope, filtering, ordering, mutation constraints and the create/append follow-up flow. The remaining gap is the absence of any hint about what a returned log looks like, which matters somewhat given there is no output schema.

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 coverage is only 50%, and the description compensates for the two substantive parameters: query is explained as searching title, description and line content (far beyond the schema's bare 'Texto a buscar'), and folderId is framed as a folder filter with a cross-reference to log_folders_list. limit/offset are left to the schema, which is acceptable for self-evident pagination integers.

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?

Opens with a concrete verb and resource: 'Lista las bitácoras (logs) del usuario y las de carpetas que le han compartido', plus ordering ('actividad más reciente primero'). It goes further and explicitly separates bitácoras from notas and expedientes, so an agent can distinguish this tool from siblings like notes_list or expedients_list without opening schemas.

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?

Gives explicit pre-use guidance ('Úsalo antes de log_create para no duplicar bitácoras'), names the conditional alternative for creating (log_create) and browsing folders (log_folders_list), and even states a decision rule for note-vs-log. When-to-use, when-not-to-use, and the follow-up flow are all present.

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