Skip to main content
Glama
rokibul-mist

rhino-mcp

by rokibul-mist

rhino_batch_call

Dispatch multiple Rhino or Grasshopper bridge methods in one round-trip to cut MCP overhead and speed up workflows that issue several back-to-back calls.

Instructions

Dispatch multiple bridge methods in a single round-trip.

    IMPORTANT: ``steps[].method`` is a **bridge dispatcher route**, not
    an MCP tool name. The MCP tool ``rhino_layer_create`` maps to the
    dispatcher route ``rhino.layer.create``; ``rhino_document_summary``
    maps to ``rhino.query.document_summary`` (NOT ``rhino.document.summary``).
    Standalone-only tools (``rhino_set_user_text`` etc. that have no
    ``bridge_call`` path) cannot be batched. A wrong route name returns
    an ``error`` row with ``HandlerError``; the batch aborts when
    ``on_error='stop'``.

    Measured impact (v0.6.x, localhost): direct sequential layer.create
    ~580ms/op vs batched ~340ms/op — N x ~240ms saved per batch (the
    MCP↔bridge round-trip cost paid once instead of N times). Effective
    for any workflow that issues >5 bridge calls back-to-back.

    Returns ``{summary: {total, ok, failed, on_error}, results: [...]}``
    where each ``results`` entry has ``index``, ``method``, ``status``
    (``"ok"`` | ``"error"``), and either ``result`` or ``error``.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are minimal (only readOnlyHint: false), so the description carries the behavioral disclosure burden and succeeds. It discloses failure modes (wrong route returns an 'error' row with HandlerError), abort semantics tied to on_error='stop', the exact return shape ({summary, results} with index/method/status/result|error), and the performance profile — all context beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Longer than typical but justified: the route-naming convention, error semantics, performance data, and return format are each non-obvious and earn their place. Content is front-loaded (purpose first, then the critical gotcha, then performance rationale, then return shape). The benchmark detail could be tighter by a sentence, but its presence directly supports the usage decision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batching tool with nested args, a route-naming trap, per-step error semantics, and an output schema, the description is remarkably complete. It covers why to use it, when to use it, what cannot be batched, how to name methods correctly, what happens on failure, and what the response looks like. The on_error parameter and batch size limits are already covered by the schema, so no required detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% at the top level, so the description must compensate, and it does so strongly for the critical 'method' parameter with mapping examples and a counterexample ('rhino.query.document_summary' NOT 'rhino.document.summary'). It also explains on_error's behavioral effect. However, the 'params' object semantics are only addressed via the schema's nested $defs ('JSON object passed verbatim'), not in the description itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opening sentence states a specific verb+resource+mechanism: 'Dispatch multiple bridge methods in a single round-trip.' It goes beyond the title by explaining what 'bridge methods' are and how they relate to MCP tool names (e.g., 'rhino_layer_create' maps to 'rhino.layer.create'), which separates it from the hundreds of individual rhino_* sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit, quantified when-to-use guidance: 'Effective for any workflow that issues >5 bridge calls back-to-back' with measured performance evidence (~580ms sequential vs ~340ms batched). It also states when-not: 'Standalone-only tools (rhino_set_user_text etc. that have no bridge_call path) cannot be batched,' giving the agent actionable exclusion criteria.

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

Install Server

Other Tools