call_source_tool

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

With no annotations, the description carries the full burden. It discloses that this is an arbitrary dispatcher, but says nothing about error behavior for unknown backend/tool names, whether mutating backend tools can be invoked through this path, or any auth/rate-limit considerations — meaningful gaps for a generic pass-through.

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?

Front-loads the core purpose in one line and follows with the Args block; nothing is padded. The reStructuredText double-backticks are cosmetic noise but negligible.

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?

An output schema exists, so return values need not be explained. However, for a generic dispatcher the description should mention failure modes (invalid names) and whether destructive backend tools are reachable — neither is covered, which leaves an agent unequipped for edge cases.

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, and it does: each of the three parameters is explained, including the crucial provenance hint that backend and tool names come from list_sources(). It stops short of describing the shape or conventions of the arguments object beyond 'JSON object'.

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?

States a specific verb and resource — call any backend tool by name — and frames itself as the 'escape hatch' for features with no cross-source wrapper, which implicitly separates it from the sibling wrappers (search_papers, get_paper). It does not explicitly name which siblings to prefer, but the examples (openreview reviews, arxiv LaTeX source) make the niche concrete.

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?

Gives a clear condition for use (backend-specific features lacking a cross-source wrapper) and directs the agent to list_sources() to discover valid backend/tool names. It never states an explicit 'do not use when a wrapper exists', but that exclusion is strongly implied by 'no cross-source wrapper'.

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