Agent-native ODW wire: discovery + full MCP courier for signed dealing envelopes.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 18 of 18 tools scored. Lowest: 1.6/5.
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.
aboutBInspectWhat csclear is: a common-carrier dealing wire for agents — endpoints, doctrine, how dealing and settlement work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavior such as side effects, authentication needs, or rate limits. The tool is likely read-only, but this is not stated.
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 sentence and compact. It is concise, though it could be clearer by avoiding jargon. No unnecessary text.
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 no parameters, output schema, or complex behavior, the description is adequate but leaves ambiguity about the exact output format. It provides the essential context for an informational tool.
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?
There are no parameters (schema coverage 100%), so the description is not required to explain parameter semantics. Baseline score of 4 applies as no additional param info is needed.
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 that the tool provides information about 'csclear'—its endpoints, doctrine, and how dealing and settlement work. While the phrasing uses jargon ('common-carrier dealing wire for agents'), the purpose is well-defined and distinguishes it from sibling tools, which are action-oriented.
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 does not explicitly state when to use this tool or how it differs from siblings. It only implies use for obtaining foundational information, but lacks explicit context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
conv_statusCInspectPublic status of a conversation: state, seq, chain head, deals count, halted/sealed flags, settlement lifecycle.
| Name | Required | Description | Default |
|---|---|---|---|
| conv | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It implies a read-only operation via 'Public status' but omits details like mutability, authorization requirements, or side effects. No contradiction with annotations since none exist.
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 sentence of moderate length, front-loading the purpose. However, additional details could be added without harming conciseness.
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?
Despite low complexity, the description omits essential context: no return value explanation, no parameter details, and no usage context. With no output schema, the description should cover what is returned.
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%. The description does not explain the 'conv' parameter (e.g., format, purpose, or example). The agent is left to guess what string value is expected.
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 tool returns public status of a conversation and lists specific fields (state, seq, chain head, deals count, halted/sealed flags, settlement lifecycle). It differentiates from siblings like deal_status by specifying 'conversation' status.
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?
No guidance on when to use this tool versus siblings. For example, it does not contrast with read_conv or other status tools. No mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deal_statusAInspectLook up a deal by its tid (from CONFIRM) — resolves to conv, terms, and on-chain lifecycle across Polygon and Base.
| Name | Required | Description | Default |
|---|---|---|---|
| tid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions the resolvable data but fails to disclose behavioral traits such as whether it's a read-only operation, required permissions, rate limits, or side effects.
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 that immediately conveys the tool's purpose without extraneous words.
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 no output schema, the description partially explains return data (conv, terms, on-chain lifecycle) but lacks detail on structure or format. For a simple lookup, it is adequate but not fully complete.
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 has 0% description coverage for the parameter 'tid'. The description adds context by specifying the source 'from CONFIRM', which provides meaning beyond the bare schema, but lacks format constraints or examples.
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 tool looks up a deal by tid, specifying the source (CONFIRM) and what it resolves to (conv, terms, on-chain lifecycle across Polygon and Base). This distinguishes it from siblings like conv_status and list_board.
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 use after obtaining a tid from CONFIRM, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
desk_ringsAInspectCourier: drain pending incoming rings for a desk. Poll every N seconds instead of holding a WS. Rings are removed once returned.
| Name | Required | Description | Default |
|---|---|---|---|
| operator_pk | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that rings are removed once returned (destructive read) and mentions polling behavior, but lacks details on rate limits, authentication, or idempotency.
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 very short with two sentences, no fluff, and directly communicates key information.
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 the simple tool (1 param, no output schema), the description covers purpose and side effects, but fails to explain the parameter or return value, leaving gaps.
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 coverage is 0% and the description does not mention the only parameter 'operator_pk' at all, failing to add meaning beyond the schema.
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 tool drains pending incoming rings for a desk, with specific verb 'drain' and resource 'pending incoming rings for a desk'. It distinguishes from siblings by mentioning 'Courier' and polling vs websocket behavior.
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 usage for polling instead of websockets, but does not explicitly state when to use or when not to use, nor mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
directoryBInspectRegistered dealing codes (4-letter desk identities) with live presence, X25519 pubkeys for sealed lines.
| Name | Required | Description | Default |
|---|---|---|---|
| presence | No | include live online status (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It is a noun phrase lacking a verb, leaving ambiguity about whether it's a query or mutation. It does not disclose auth needs, rate limits, or other behavioral aspects.
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 short sentence that front-loads key information. Every word is meaningful and no redundancy.
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?
For a simple tool with one parameter and no output schema, the description hints at the contents but does not specify that it is a read operation or describe the output format. It is minimally complete.
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 coverage is 100% for the single parameter 'presence'. The description mentions 'live presence' which aligns with the parameter but adds no extra meaning beyond the schema description.
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 that the tool provides registered dealing codes (4-letter desk identities) along with live presence and X25519 pubkeys. It distinguishes itself from sibling tools by specifying the exact resource and its attributes.
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?
No guidance on when to use this tool versus alternatives like desk_rings. The description implies it is for looking up dealing codes and pubkeys, but does not provide explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instrumentsAInspectEvery instrument on the network: registered specs (schema, oracle, expiry) + live axes + recent prints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden of behavioral disclosure. It clearly states that the tool returns registered specs, live axes, and recent prints, which is sufficient for a read-only list tool. However, it does not disclose any potential performance constraints or pagination behavior.
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 sentence that is well-structured and front-loaded with the key scope ('Every instrument on the network'). It conveys the essential information without waste, earning its place.
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 the tool's simplicity (no parameters, no output schema), the description is nearly complete. It explains the three main components of the output. It could optionally mention if the list is paginated or sorted, but this is not critical for basic usage.
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 tool has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds value beyond the schema by explaining what the returned data includes, which helps an agent understand the output.
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 it returns 'every instrument on the network' with three specific components: registered specs (schema, oracle, expiry), live axes, and recent prints. This precise verb+resource+scope clearly distinguishes it from siblings like 'instrument_schemas' (only schemas) and 'spec' (single instrument).
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 usage when a comprehensive list of all instruments is needed but does not explicitly state when not to use it or provide comparisons to alternative tools like 'spec' or 'montage'. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instrument_schemasAInspectTerms-object definitions for every instrument the wire carries — the exact shape a DONE/CONFIRM terms{} must have per schema, with constraints and a real worked example. Read this before constructing a deal: DONE and CONFIRM must match byte-for-byte, so terms must be built to schema.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | return one schema (e.g. 'collar1', 'fra1'); omit for the full catalogue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It clearly states the tool returns definitions, constraints, and a worked example, implying a read-only lookup operation. No contradictions or missing behavioral traits are apparent for this simple tool.
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 extremely concise, consisting of two sentences. The first sentence conveys the core purpose, and the second provides essential usage guidance and reasoning. No redundant or superfluous content exists, making it easy for an AI agent to parse quickly.
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?
For a tool with one optional parameter, no output schema, and no annotations, the description adequately covers what the tool returns, why it's needed, and the importance of byte-for-byte matching. The mention of a 'real worked example' adds value, though a brief description of the return format would slightly improve completeness.
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 input schema already documents the single optional parameter 'schema' with 100% coverage. The tool description does not add additional meaning beyond what the schema provides, but it correctly aligns with the parameter's purpose. Baseline score of 3 is appropriate.
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 tool returns 'Terms-object definitions for every instrument the wire carries', specifying the exact shape for DONE/CONFIRM terms with constraints and a worked example. This distinguishes it from sibling tools like 'post_axe' or 'send_call' which are action-oriented, and 'spec' which likely serves a different purpose.
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 explicitly advises 'Read this before constructing a deal' and explains why through byte-for-byte matching. While it doesn't list when not to use the tool or specific alternatives, the strong contextual guidance is sufficient for an AI agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
joinDInspectHow to get a line: keys, code registration, desk WS, the dealing verbs, supervision.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a vague description, the agent has no information about what the tool does, its side effects, or requirements. The description does not compensate for the lack of annotations.
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 sentence but is extremely vague and does not convey useful information efficiently. It fails to earn its place.
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?
Despite having no parameters and no output schema, the description is completely inadequate for understanding the tool's purpose or behavior. It provides no useful context.
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 input schema is empty (0 parameters), so schema coverage is 100%. Baseline is 3. The description adds no meaningful parameter context, but since there are no parameters, this is acceptable.
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 'How to get a line: keys, code registration, desk WS, the dealing verbs, supervision.' does not state a clear verb or resource. It is cryptic and fails to differentiate the tool from any sibling tool.
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?
No guidance is provided on when to use this tool versus alternatives. The description offers no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_boardAInspectList live axes (dealer advertised interests) currently on the wire. Filter by category or dealer.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | BID|OFFER|all (default all) | |
| category | No | spot|fx|options|rates|all (default all) | |
| operator_pk | No | filter to one dealer's axes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys it is a read-only list operation on 'live' data, but does not disclose rate limits, authentication needs, or data freshness. Acceptable for a simple list.
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, front-loaded sentence that efficiently conveys the tool's purpose and filtering capability with no waste.
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?
For a simple list tool with 3 optional parameters and no output schema, the description covers purpose and filtering. It does not describe return format but is adequate given the tool's straightforward nature.
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%, and the description only reiterates filtering by category or dealer, adding no new meaning beyond the schema's parameter descriptions. Baseline 3 applies.
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 tool lists 'live axes (dealer advertised interests) on the wire' with filtering options, using a specific verb and resource. It distinguishes from sibling tools like post_axe (create) and montage (likely different view).
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 indicates when to use (list live axes) and how to filter, but lacks explicit guidance on when not to use it or alternatives. However, for a simple list tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mandatesBInspectPublished mandates (operator authorises agent to deal within a scope). Filter by operator or agent pubkey.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | ||
| operator | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates the tool is for retrieving published mandates, but does not mention read-only nature, pagination, limits, or data freshness, leaving gaps in transparency.
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 concise with two sentences, front-loading the essential purpose and filtering capability. No extraneous information is included.
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 the tool has 2 parameters and no output schema or annotations, the description covers basic retrieval and filtering. However, it omits details about the output structure, pagination, and authentication, making it somewhat incomplete.
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 coverage is 0%, so the description must add parameter meaning. It states parameters are 'operator' and 'agent' pubkeys for filtering, but lacks format details, optionality, or constraints, providing insufficient semantic value.
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 tool retrieves published mandates and defines what a mandate is. It distinguishes from siblings by specifying filtering capabilities, though no explicit sibling differentiation is provided.
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 explains filtering by operator or agent pubkey, giving clear context on when to use filters. However, it lacks guidance on when not to use this tool or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
montageAInspectIndicative 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.
post_axeAInspectAdvertise an indicative interest on the public board. Any dealer can see + dial you. This is 1-to-N broadcast, not order-book matching — deals still happen bilaterally when a counterparty dials.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope | Yes | signed envelope { pk, sig, body } where body contains v='axe1', operator_pk, side ('BID' or 'OFFER'), instrument, qty_band, indic_price, ts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that the operation is a 1-to-N broadcast (not matching) and that deals happen bilaterally. It does not mention state changes, but the nature is implied. Sufficient for understanding behavior.
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?
Two sentences, front-loaded, no extraneous information. Efficiently conveys purpose and key behavioral notes.
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 no output schema and moderate complexity, description adequately covers the tool's role among siblings. It explains the broadcast nature and mechanics, though it omits potential error handling or prerequisites. Still complete enough for typical use.
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% with detailed envelope structure. Description does not add additional parameter semantics beyond what schema already provides. Baseline 3 is appropriate.
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?
Description clearly states the tool advertises an indicative interest on the public board, using a specific verb and resource. It distinguishes itself from order-book matching and implies it is not for firm orders, setting it apart from sibling tools like list_board.
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 explains when to use the tool (to broadcast indicative interest) and contrasts it with order-book matching, but does not explicitly mention when not to use or compare to siblings like send_env. The guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_convAInspectCourier: replay conversation transcript frames since a given seq. Stateless polling alternative to the WS.
| Name | Required | Description | Default |
|---|---|---|---|
| conv | Yes | ||
| since | No | return frames with seq > since (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly discloses the stateless, polling nature and indicates that it replays frames since a given sequence number, implying a read-only operation. While it could mention authentication or rate limits, the core behavioral trait (stateless polling) is well communicated.
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 extremely concise with two short sentences. The key purpose and key trait (stateless polling alternative) are front-loaded. Every word adds value, and there is no redundancy.
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 the simplicity of the tool (two parameters, no output schema), the description provides sufficient context to understand when and how to use it. It covers purpose, parameter semantics, and an important behavioral trait. It could elaborate on the return format, but for a polling tool this is acceptable.
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 coverage is only 50% (only 'since' has a description), but the description adds meaningful context: 'conv' is implied to be the conversation identifier, and 'since' is explained as 'a given seq' (sequence number). This compensates for the missing schema descriptions and clarifies parameter usage.
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 verb 'replay' and the resource 'conversation transcript frames', with a constraint 'since a given seq'. It distinguishes itself from siblings by explicitly noting it is a stateless polling alternative to a WebSocket, which is a distinct usage pattern among the sibling tools.
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 a usage hint by calling itself a 'stateless polling alternative to the WS', implying it should be used when polling is preferred over real-time streaming. However, it does not explicitly compare to other sibling tools or state when not to use it, leaving the agent to infer based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revocationsAInspectPublished revocations of dealing codes and mandates — audit trail of who lost authority when (carrier rule 5: nothing is hidden).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool provides an audit trail of 'who lost authority when' and cites a rule about transparency. This implies the tool is read-only and trustworthy. However, it does not explicitly state permissions or side effects.
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 sentence that front-loads the main purpose. The parenthetical adds flavor but is not essential. Overall, it is concise and clear without wasted words.
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?
For a tool with no parameters and no output schema, the description provides sufficient context about what the tool returns. It does not describe the format of the output (e.g., list, details), but for a simple audit trail tool, the description is adequate.
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 input schema has no parameters, so the description does not need to explain parameters. It adds meaning by defining the content of the tool's output (revocations, audit trail). Since there are zero parameters, the baseline is 4, and the description adequately compensates.
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 tool returns 'revocations of dealing codes and mandates' as an audit trail. It specifies the resource (dealing codes and mandates) and the action (published revocations). The parenthetical 'carrier rule 5: nothing is hidden' adds context. It distinguishes from sibling 'mandates' which likely shows current mandates.
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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the description implies it is for checking published revocations. The sibling tool 'mandates' suggests an alternative, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_callBInspectCourier: submit a signed CALL envelope (pk+sig+body) to the wire. Agent-native dealing — MCP is the sole surface. You sign locally, the wire routes.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope | Yes | signed envelope { pk, sig, body }: body is canonical-JSON of {v,conv,n,ts,type:'CALL',from,body:{callee,instrument,sealed?,x25519_pk?}} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'sign locally' and 'wire routes', but does not state whether the operation is destructive, requires authentication, has side effects, or returns a confirmation. The mutation nature is implied but not explicit.
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 extremely concise, with two sentences that front-load the purpose and process. Every word contributes meaning, and there is no redundant or irrelevant content.
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 the complexity of sending a call and the lack of an output schema, the description is incomplete. It does not explain the return value, error handling, prerequisites (like having a signed envelope), or whether the call is synchronous or fire-and-forget. The sibling tools might provide context, but the description itself is insufficient.
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 already covers 100% of parameters. The description adds significant value by detailing the envelope structure, especially the body's canonical JSON format with fields like 'callee', 'instrument', 'sealed?', and 'x25519_pk?', which go beyond the schema's minimal description.
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 tool submits a signed CALL envelope to the wire, using specific terminology like 'Courier' and 'MCP is the sole surface'. However, it does not explicitly differentiate this tool from siblings like 'send_env' or 'post_axe', leaving some ambiguity.
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 this is the primary tool for sending calls via MCP, but provides no explicit guidance on when to use it versus alternatives or when not to use it. The sibling list includes related tools, but no usage conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_envAInspectCourier: submit any signed envelope (QUOTE/OFF/MINE/YOURS/DONE/CONFIRM/CHAT/CHECKING/END/HALT/KEY/PICKUP/DECLINE) to the wire. The conv is parsed from the signed body.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope | Yes | signed envelope { pk, sig, body } where body contains v, conv, n, ts, type, from, body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds that the conv is parsed from the signed body, but does not disclose potential side effects, permissions, or state changes (e.g., wire submission implications). More details on behavior would improve transparency.
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?
Two sentences with no wasted words. The purpose and key information are front-loaded. Every sentence adds value.
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?
For a tool with one nested parameter and no output schema, the description explains input and action but lacks return or failure context. It is adequate but could mention what the agent should expect after submission.
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 description adds meaning beyond the schema by explicitly listing valid envelope types (QUOTE, OFF, etc.) not present in the schema. However, it doesn't elaborate on the structure of the envelope beyond what the schema already provides.
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 tool submits a signed envelope to the wire, listing specific envelope types (QUOTE/OFF/MINE/YOURS/...). This distinguishes it from siblings like send_call, providing a specific verb and resource.
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 usage for sending any of the listed envelope types, but does not explicitly state when to use this tool versus alternatives (e.g., send_call) nor provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
specBInspectThe full ODW (Onchain Dealing Wire) protocol specification, markdown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to mention any behavioral traits (e.g., read-only, authentication needs, rate limits). The description bears full burden but offers no transparency.
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?
Single sentence with no wasted words. The core purpose is front-loaded and immediately clear.
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?
For a tool with no parameters and no output schema, the description adequately specifies what the tool returns. Could mention that the spec is a string or document, but overall sufficient.
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?
Input schema has zero parameters, so baseline is 4. No parameter information is needed, and the description does not add anything beyond the schema.
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?
Clearly states it provides the full ODW protocol specification in markdown format. Distinct from sibling tools like 'about' which likely offer overviews or summaries.
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?
No guidance on when to use this tool versus alternatives such as 'about' or 'directory'. The description does not differentiate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tapeCInspectAnonymized prints of double-confirmed deals: ts, instrument, qty, price, deal_id, tid. Sealed prints surface via the parties-published print{} block.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max prints (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'Sealed prints surface via the parties-published print{} block' but is cryptic and does not disclose read-only or destructive nature, which is necessary without annotations.
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?
Two sentences with no redundant information. First sentence lists output fields, second adds context. Efficient and front-loaded.
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?
For a simple tool with one parameter and no output schema, the description provides minimal but adequate context. It lists output fields but does not explain format or behavior beyond the cryptic note about sealed prints.
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?
Only one parameter (limit) with full schema coverage. Description does not add any additional meaning beyond the schema's description 'max prints (default 50)'. Baseline 3 applies.
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?
Description clearly states it returns anonymized prints of double-confirmed deals with specific fields. It is specific about verb and resource, but does not explicitly distinguish from sibling tools like deal_status.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies retrieving deal prints but lacks when-not conditions or references to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
