Rowan MCP Server

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a submission tool (implies mutation/write operation), mentions credit spending ('max_credits'), and provides practical context like default values and performance implications ('Higher values = more thorough but slower'). However, it doesn't explicitly state error conditions or rate limits.

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?

Perfectly structured and front-loaded: purpose statement first, then parameter details with clear explanations, followed by usage scenarios and return information. Every sentence adds value with no redundancy. The example is appropriately placed at the end for illustration without disrupting the flow.

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 9-parameter tool with no annotations and no output schema, the description does an excellent job covering purpose, parameters, usage, and behavior. It provides a concrete example showing proper invocation. The only minor gap is lack of explicit information about return format details beyond 'Workflow object', but this is partially mitigated by the example showing usage.

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 100%, so the baseline is 3. The description adds significant value by explaining parameter semantics beyond the schema: it clarifies protein can be 'PDB ID string' or 'Protein UUID string', specifies pocket format as 'JSON string "[[x1,y1,z1], [x2,y2,z2]]"', and explains the practical meaning of 'exhaustiveness' and 'max_credits'. The example also demonstrates proper parameter usage.

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 batch docking workflow') and resource ('for high-throughput virtual screening using Rowan v2 API'), distinguishing it from siblings like 'submit_docking_workflow' (single docking) and other workflow types (e.g., 'submit_admet_workflow'). It explicitly mentions handling multiple ligands against a single protein target.

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 usage scenarios ('Useful for: - Virtual screening campaigns - Lead optimization - Fragment library screening - Structure-activity relationship studies'), which clearly indicate when to use this tool. It differentiates from siblings by focusing on batch processing of multiple ligands, unlike 'submit_docking_workflow' which likely handles single ligands.

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