Skip to main content
Glama
thyn-ai

Algenta

Official
by thyn-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

route_capabilities

Read-onlyIdempotent

Selects the right unified capability for a plain-language goal and returns its route plan: capability, binding, owner, approval need, confidence, fallbacks. Read-only; pass selection ID to execute.

Instructions

Pick the best unified capability for a natural-language objective and return the route plan: the selected capability, binding, and kind, the authoritative execution_owner, whether approval is required, confidence and reason, plus ordered fallbacks (max_fallbacks, default 3). The optional filters narrow which catalog entries may be selected. Routing never executes anything — feed the selected_capability_id to execute_capability. This picks a capability for an objective; it is not decision analysis — use plan_decision or simulate for a DecisionPlan or full risk envelope instead. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoPrefer capabilities carrying these tags.
kindsNoRestrict candidates to these capability kinds.
objectiveYesWhat you want to accomplish, in plain words.
binding_idsNoRestrict candidates to these bindings.
provider_idsNoRestrict candidates to these providers.
max_fallbacksNoHow many fallback routes to return, 0-10; defaults to 3.
execution_ownersNoRestrict candidates to these execution owners.
artifact_affinitiesNoPrefer capabilities affine to these artifacts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.1.3
    • addedInput schema / properties / artifact_affinities / description
      Added value: +"Prefer capabilities affine to these artifacts."
    • addedInput schema / properties / binding_ids / description
      Added value: +"Restrict candidates to these bindings."
    • addedInput schema / properties / execution_owners / description
      Added value: +"Restrict candidates to these execution owners."
    • addedInput schema / properties / kinds / description
      Added value: +"Restrict candidates to these capability kinds."
    • addedInput schema / properties / max_fallbacks / description
      Added value: +"How many fallback routes to return, 0-10; defaults to 3."
    • addedInput schema / properties / objective / description
      Added value: +"What you want to accomplish, in plain words."
    • addedInput schema / properties / provider_ids / description
      Added value: +"Restrict candidates to these providers."
    • addedInput schema / properties / tags / description
      Added value: +"Prefer capabilities carrying these tags."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description aligns and adds value by stating 'Routing never executes anything' and clarifying that the result reports whether approval is required. This goes beyond the structured annotations and matches them, with no contradiction.

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

Conciseness5/5

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

The description is dense but front-loaded: it opens with the core purpose and output, then covers filters, non-execution behavior, follow-up action, and alternatives. Every sentence contributes routing-relevant information without redundancy.

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

Completeness4/5

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

With no output schema, the description compensates well by enumerating the route plan fields, fallback behavior, and execution handoff. Given the tool's moderate complexity and rich annotations, the only minor gap is a formal output shape, but the description provides enough for an agent to call and interpret the result correctly.

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

Parameters3/5

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

The schema provides 100% description coverage of all eight parameters, so the baseline is 3. The description adds general context that filters narrow candidate catalog entries and notes max_fallbacks defaults to 3, but it does not need to elaborate because every parameter is already documented in the schema.

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?

The description states a specific verb and resource: pick the best unified capability for a natural-language objective and return a route plan. It further details the output fields and explicitly distinguishes this tool from execute_capability and decision-analysis tools, making the purpose unmistakable.

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?

It gives explicit when-to-use guidance: use this for selecting a capability, then feed the selected_capability_id to execute_capability. It also names the alternatives, plan_decision and simulate, and states this is not decision analysis, so the agent knows exactly when to choose a different sibling.

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

Deploy Server

Other Tools