ocr_manage_contact

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

With no annotations, the description carries the full burden of behavioral disclosure. Saying 'CRUD operations' hints at create, read, update, and delete side effects, but it does not clarify destructive behavior, idempotency, required preconditions, or what happens on invalid inputs. This is insufficient for a tool that can mutate data.

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 short and front-loaded, naming the resource immediately. However, the brevity comes at the cost of substance; the single sentence uses its space only for a broad statement and omits any operational details that would justify its usefulness.

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?

Given three parameters, no annotations, no output schema, no enums, and several sibling tools, this description is incomplete. An agent cannot determine valid action values, how tax_id and company_name relate to CRUD operations, or what result to expect. More context is required for reliable 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%, and the description adds no meaning for the three parameters. The critical 'action' parameter is completely undefined, 'tax_id' is required but unexplained, and 'company_name' is not mentioned at all. The description does nothing to compensate for the schema's lack of documentation.

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 identifies a clear resource, the contacts database, and the general operation type, CRUD. However, 'CRUD operations' is broad and does not specify which action is being performed; the agent must infer from the undocumented action parameter. It distinguishes from siblings by resource, but not by operation type.

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?

No guidance is provided about when to use this tool versus alternatives such as ocr_get_record or ocr_list_records. There are no exclusions, prerequisites, or conditions that would help an agent decide between this and a sibling tool.

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