Route a tool call through HumanMirror Nexus. Use nexus_search first, then call the selected tool_id. Successful calls consume the number of Nexus credits declared by the selected tool.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | JSON input forwarded to the selected tool. | |
| options | No | Optional tool-specific options. | |
| tool_id | Yes | A tool_id returned by nexus_search, for example forge.clean_json. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly warns that successful calls consume Nexus credits, which is a critical non-obvious side effect. It does not cover failure behavior or authorization, but the most important consequence for an agent is disclosed.
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?
The description is three short sentences, each earning its place: the first states purpose, the second gives prerequisite workflow, and the third reveals the credit cost. It is front-loaded and contains no filler.
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?
The description covers the workflow, credit side effect, and tool_id provenance, which is solid for a routing tool. However, with no output schema and no annotations, it does not explain what the caller should expect as a return value or how errors surface, leaving some operational ambiguity.
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 does not add meaning beyond what the schema already states: 'tool_id returned by nexus_search' is copied in the schema, and 'input' is already described as forwarded JSON. No additional parameter nuance is provided.
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 opens with a clear verb and resource: 'Route a tool call through HumanMirror Nexus.' It also differentiates itself from the sibling nexus_search by instructing to 'Use nexus_search first, then call the selected tool_id,' making the tool's role as the execution step unmistakable.
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 workflow context: nexus_search must precede nexus_call, and the tool_id must come from that search. It does not spell out when not to use the tool or mention alternatives beyond nexus_search, so it stops short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools divide cleanly into nexus routing and outcome contract flows, but magnet_resolve and nexus_search both perform free task-to-tool matching, which could cause an agent to pause over which discovery path to use. All other tools have clearly distinct roles.
Every tool follows the same noun_verb snake_case pattern: magnet_resolve, nexus_call, nexus_search, outcome_quote, outcome_run, outcome_verify. The prefix groups reinforce the two subsystems while keeping a single consistent naming convention.
Six tools is well-scoped for a bridge/marketplace server: two for standard Nexus discovery and execution, one fallback discovery mechanism, and three for the Outcome contract lifecycle. Each tool earns its place without redundancy.
The server covers the full agent-facing workflow: discover a tool, execute it, and separately quote, run, and verify success-only Outcome contracts. It also records capability gaps through magnet_resolve, leaving no obvious dead end for the stated purpose.