vector_rejection

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

No annotations are provided, so the description carries the full burden. It states the tool calculates vector rejection but does not disclose behavioral traits such as input validation (e.g., handling non-numeric strings in arrays), error handling (e.g., zero vectors), output format, or computational characteristics. The description is minimal and lacks necessary operational details.

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 concise and front-loaded with the core purpose in the first phrase. It avoids unnecessary words, though the domain and category annotations are appended efficiently. However, it could be more structured by separating usage notes from the core description.

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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameter semantics, behavioral transparency, and output expectations. For a mathematical tool with two parameters, more context is needed to guide effective use, such as input formats and result interpretation.

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%, so the description must compensate. It does not explain the parameters 'vector_a' and 'vector_b' beyond implying they are vectors. No details on array format (e.g., numeric strings, length requirements), meaning of the vectors in the rejection calculation, or examples are provided. The description adds little semantic value over the bare schema.

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 purpose: 'Calculate vector rejection (component perpendicular to another vector)'. It specifies the verb ('calculate'), resource ('vector rejection'), and defines the mathematical concept. However, it does not explicitly differentiate from sibling tools like 'vector_projection' or 'normalize_vector', which are related vector operations.

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 provides minimal guidance: it includes a domain ('linear_algebra.vectors') and category ('general'), which implies context but does not specify when to use this tool versus alternatives like 'vector_projection' or 'cross_product' for perpendicular components. No explicit when-to-use, when-not-to-use, or prerequisite information is given.

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