Rowan MCP Server

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

With no annotations provided, the description carries full burden and does an excellent job disclosing key behavioral traits: performance characteristics (8x speed difference, ~5 min vs ~40 min runtime), waiting requirements ('WAIT ~5 min (fast) or ~40 min (slow)'), polling guidance ('Use workflow_is_finished() to poll'), and rate limit warnings ('not more than once per minute to avoid loops'). It doesn't cover all possible edge cases, but provides substantial operational context.

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 well-structured with clear sections (purpose, performance, modes, args, returns, examples) and every sentence adds value. It could be slightly more concise in the parameter explanation section, but overall it's efficiently organized with no wasted text.

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 complex 10-parameter workflow tool with no annotations and no output schema, the description provides excellent context: clear purpose, detailed usage guidelines, performance expectations, runtime behavior, and practical examples. The main gap is the lack of information about the return format ('Workflow object' is vague), but given the comprehensive operational guidance, this is a minor limitation.

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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the practical implications of key parameters: it clarifies that compute_aqueous_solubility=False enables 'fast mode' for relative comparisons while True enables 'slow mode' for absolute values, and provides performance context. However, it doesn't add meaningful context for all 10 parameters beyond what the schema provides.

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 specific action ('Submit a Macroscopic pKa workflow') and resource ('using Rowan v2 API'), with detailed explanation of what it calculates (pKa values, microstate populations, net charge across pH range). It effectively distinguishes from siblings by focusing on macroscopic pKa calculations, unlike other workflow tools for different purposes like docking or solubility.

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 explicit guidance on when to use fast vs. slow modes: 'Fast mode (False): ... Sufficient to determine which pH has highest/lowest solubility' and 'Slow mode (True): ... Only needed for absolute values or fold-changes.' It also includes practical examples with specific use cases, making it clear when to choose each alternative.

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