evaluate_sage

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'Variables and definitions persist across calls.' It does not cover error handling or security risks, but for an arbitrary code execution tool, the persistence disclosure is significant and goes beyond the schema.

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 front-loaded with a clear purpose statement, then organized into a domain-by-domain example list. Although long, the structure makes it scannable and the examples are purposeful for an arbitrary-code tool. It is appropriately sized for the tool's complexity, though slightly verbose.

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?

The tool is complex, but the description covers core context: persistence, general-purpose scope, and relationship to specialized helpers. The output schema exists to document return values, and parameters are fully documented in the schema. It doesn't mention session reset/cancel, but the sibling tools reset_sage_session and cancel_sage_session cover that.

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 100%, so the baseline is 3. The description's lengthy domain-based examples add real semantic value for the 'code' parameter, illustrating valid SageMath syntax and showing the breadth of supported operations beyond the schema's simple 'SageMath code to execute'.

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 begins with a specific verb and resource: 'Execute arbitrary SageMath code within a persistent session.' It clearly distinguishes itself from the many sibling tools by stating it is the general-purpose fallback for 'any computation not covered by the specialized helpers.'

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?

It explicitly says 'Use this for any computation not covered by the specialized helpers,' which tells the agent exactly when to choose this tool over the specialized siblings. This is a clear usage directive with an implied alternative set.

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