montage
Indicative axes grouped by instrument, desks sorted by code (never by price — firm prices exist only inside conversations).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| instrument | No | filter to one instrument label |
Indicative axes grouped by instrument, desks sorted by code (never by price — firm prices exist only inside conversations).
| Name | Required | Description | Default |
|---|---|---|---|
| instrument | No | filter to one instrument label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states that desks are sorted by code and not by price, which is useful behavioral info. However, it does not disclose whether the tool is read-only or if any side effects occur.
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 a single, concise sentence with no redundant words. Every part contributes to understanding the tool's output and behavior.
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?
Given simplicity (1 optional param, no output schema), the description is mostly complete. It explains the output structure and sorting. One small gap: it doesn't define 'indicative axes' or state the default when no instrument is provided.
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?
The schema describes the parameter 'instrument' as a filter; the description adds that results are grouped by instrument, providing context beyond the schema. This is valuable for understanding the filter's role.
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 clearly states the output is 'indicative axes grouped by instrument, desks sorted by code', which conveys the purpose. However, it lacks an explicit verb like 'retrieves' or 'lists', making it slightly indirect.
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 implies when to use by noting that prices are not included (firm prices exist in conversations), giving a hint to alternatives. But it does not explicitly state when to use this tool over siblings like 'tape' or 'instruments'.
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.
Each tool targets a distinct aspect of the dealing wire (e.g., conv_status vs. deal_status, directory vs. instruments), with no obvious overlap. Descriptions clearly differentiate their purposes.
Tool names are mostly snake_case and descriptive, but vary between noun phrases (e.g., 'about', 'montage') and verb phrases (e.g., 'post_axe', 'send_call'). The pattern is not fully uniform but remains clear and readable.
With 18 tools, the server covers documentation, status queries, listing, and actions for a complex protocol. The count is well-scoped, avoiding both excess and insufficiency.
The tool surface provides full lifecycle coverage: reading schemas, posting axes, sending envelopes, polling rings, and inspecting deals and conversations. No obvious gaps for the stated purpose of agent-based dealing on the wire.