Skip to main content
Glama
HyperRouteAI

hyperroute-mcp

Official
by HyperRouteAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

execute

Run an external tool server-side through HyperRoute's proxy using a tool ID and literal query; the server holds the key and returns only the result.

Instructions

Run a tool server-side via HyperRoute's proxy: HyperRoute executes the tool with the server-held key and returns ONLY the result. This is the ONLY sanctioned way to run an external tool — you never call the tool's API yourself. tool_id comes from the → row of recommend; pass that ranking's session_id too. Requires login.

query is the LITERAL, self-contained input the tool consumes — the actual claim to fact-check, the search terms, the text to process — NOT a description or a back-reference to earlier turns. The tool runs in an isolated sandbox and CANNOT see this conversation, so a query like "the claim the user mentioned" reaches it empty and yields nothing.

Reading the result:

  • error: "needs_onboard" → a key IS required and missing. Use connect_info to show the user the signup URL + steps, collect their key, onboard it, then retry. Onboarding helps here.

  • error: "execute_failed"/"transport_error" with auth_method: "none" → a keyless tool failed at its endpoint; onboarding won't help (read hint). Try another tool, don't retry blindly or attempt to onboard.

  • error: "use_native"/"route_to_local" → this task is for YOU / the local runner, not server-side. For use_native, perform the task yourself with your own tools.

  • overflow: {ref, bytes, preview, resource_url} (no result) → the result was too large to inline and is retained server-side, NOT lost. Read it with fetch_result(ref, …) (or GET resource_url with your bearer for the full bytes). Never treat an overflow as missing data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
tool_idYes
session_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.1
    • addedInput schema / properties / session_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Session Id"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: server-held key, login requirement, isolated sandbox with no conversation visibility, non-retry guidance on keyless failures, and the overflow contract (result retained server-side, not lost). This is far beyond what any structured field provides.

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?

Front-loaded purpose sentence, then a clearly separated 'Reading the result' block, so the length is structured rather than rambling. It is still long relative to three parameters; a couple of the error branches could be tightened, but nearly every sentence earns its place as workflow guidance.

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?

With no output schema, the description still enumerates the return shapes (error variants, overflow object with ref/bytes/preview/resource_url) and points to `fetch_result` for large payloads. Nothing an agent needs to invoke this correctly or interpret the response is missing.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and does: `tool_id` is sourced from the `→` row of `recommend`, `session_id` from that same ranking, and `query` is defined as literal self-contained input rather than a back-reference, with a concrete failure example. All three parameters gain real semantics.

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?

States a specific verb and mechanism ('Run a tool server-side via HyperRoute's proxy') and immediately draws the boundary that this is the ONLY sanctioned way to run an external tool, distinguishing it from the other 21 siblings. An agent knows exactly what this does without opening the schema.

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?

Explicit routing rules: needs_onboard → use connect_info/onboard then retry; auth_method:none failure → don't onboard, try another tool; use_native/route_to_local → do it yourself locally. It also names `recommend` as the upstream source of inputs. This is a complete when/when-not/alternative map.

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