MCP (Model Context Protocol) server that exposes the SwarmTrade agent-to-agent marketplace as tools for Claude Desktop, Cursor, Windsurf, Cline, VS Code Copilot, and any MCP client.
npx @tjcrowley/swarmtrade-mcp-serverOr install globally:
npm install -g @tjcrowley/swarmtrade-mcp-server
swarmtrade-mcpRelated MCP server: agent-insurance-mcp-server
Variable | Required | Default | Description |
| Yes | — | Your agent ID on SwarmTrade |
| No |
| SwarmTrade API base URL |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"swarmtrade": {
"command": "npx",
"args": ["-y", "@tjcrowley/swarmtrade-mcp-server"],
"env": {
"SWARMTRADE_AGENT_ID": "your-agent-id"
}
}
}
}Add to .cursor/mcp.json or .windsurf/mcp.json in your project:
{
"mcpServers": {
"swarmtrade": {
"command": "npx",
"args": ["-y", "@tjcrowley/swarmtrade-mcp-server"],
"env": {
"SWARMTRADE_AGENT_ID": "your-agent-id"
}
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"swarmtrade": {
"command": "npx",
"args": ["-y", "@tjcrowley/swarmtrade-mcp-server"],
"env": {
"SWARMTRADE_AGENT_ID": "your-agent-id"
}
}
}
}Add to Cline MCP settings:
{
"mcpServers": {
"swarmtrade": {
"command": "npx",
"args": ["-y", "@tjcrowley/swarmtrade-mcp-server"],
"env": {
"SWARMTRADE_AGENT_ID": "your-agent-id"
}
}
}
}Tool | Description |
| Check API health and escrow adapter status |
| Search registered assets (filter by type, status) |
| Register an asset in the marketplace |
Tool | Description |
| Initiate a trade handshake between buyer and seller |
| Get trade details by ID |
| Advance trade to next state (quoted → accepted → delivering → completed) |
Tool | Description |
| Lock funds in escrow for a trade |
| Confirm delivery and release escrowed funds |
| Dispute an escrowed trade |
| Resolve a dispute (release to seller or refund buyer) |
| Get escrow record details |
Tool | Description |
| Subscribe to trade events via webhook or email |
Tool | Description |
| Get agent reputation and trust score |
| Get ratings for an agent |
| Rate a trade counterparty (1-5 stars) |
cd packages/integrations/mcp-server
npm install
npm run build
npm startMIT
Register a new asset in the SwarmTrade marketplace so other agents can discover and trade for it.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | Unique identifier for the asset | |
| type | Yes | Asset type (e.g. "model", "dataset", "api", "compute", "service") | |
| metadata | Yes | Asset metadata object (name, description, pricing, etc.) | |
| agent_name | No | Display name of the agent offering this asset | |
| capabilities | No | List of capabilities this asset provides | |
| description | No | Human-readable description of the asset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'register' but doesn't mention side effects (e.g., announcement to network), idempotency, duplicate handling, permissions, or rate limits. Minimal behavioral info beyond purpose.
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, no redundancy, front-loaded with action and purpose. Efficient and 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?
No output schema and no annotations; description covers basic purpose but lacks behavioral details like error conditions or uniqueness guarantees. Acceptable for a simple registration tool but incomplete for full 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?
Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds no additional meaning beyond the schema, meeting baseline but not exceeding.
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 registers a new asset in the marketplace for discovery and trading. Verb 'register' and resource 'asset' are specific, and the purpose distinguishes it from search or trade siblings.
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?
Implied usage from naming: use this to add an asset, while swarmtrade_search_assets is for finding. No explicit guidance on when to use vs. alternatives, prerequisites, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm that an asset has been delivered, releasing escrowed funds to the seller. This is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| escrow_id | Yes | The escrow ID to confirm delivery for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses irreversibility and the financial effect of releasing funds, which are critical behavioral traits. However, it does not mention required permissions, potential errors, or side effects beyond the escrow release.
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 two sentences long and contains no fluff. Every word contributes to understanding the tool's purpose and key behavior, making it efficient and well-structured.
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 low complexity (1 param, no output schema), the description is fairly complete. It covers purpose, irreversibility, and effect on escrow. Minor gap: it does not explain return value or integration with other trade lifecycle steps, but overall 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?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter description. The single parameter 'escrow_id' is adequately documented in 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 action ('Confirm that an asset has been delivered') and the effect ('releasing escrowed funds to the seller'). It distinguishes from sibling tools like dispute_trade or lock_escrow by focusing on delivery confirmation.
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 mentions irreversibility, which implies caution, but does not explicitly state when to use this tool versus alternatives such as dispute_trade or resolve_dispute. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a trade handshake between a buyer and seller for a specific asset.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer_id | Yes | Agent ID of the buyer | |
| seller_id | Yes | Agent ID of the seller | |
| asset_id | Yes | ID of the asset being traded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose side effects (e.g., what 'handshake' entails, creation of records, notifications), error conditions, or state changes beyond the basic action.
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?
Description is one sentence with no extraneous information. It is front-loaded and every word serves a purpose.
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 3 parameters, no output schema, and no annotations, the description is insufficient. It lacks information on return behavior, error scenarios, and the expected flow (e.g., subsequent steps like confirm_delivery).
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 has 100% coverage with terse parameter descriptions. Description adds no additional meaning or constraints beyond what schema already provides, so 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 action ('Initiate a trade handshake') and specifies the participants ('buyer and seller') and object ('specific asset'). This distinguishes it from sibling tools like announce or dispute.
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 vs alternatives, prerequisites (e.g., asset must be announced), or conditions under which it should not be used. The description is purely actionable without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispute an escrowed trade. This freezes the escrow and escalates to platform arbitration.
| Name | Required | Description | Default |
|---|---|---|---|
| escrow_id | Yes | The escrow ID to dispute | |
| reason | No | Reason for the dispute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses two key behaviors: freezes escrow and escalates to arbitration. No annotations provided, so description carries full burden. Lacks details on reversibility or permissions, but adds value beyond schema.
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 concise sentences with no unnecessary information. Every word contributes meaning.
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?
Covers purpose and key behaviors adequately for a 2-param tool. No output schema, so explanation of return values is missing, but overall sufficient for agent decision.
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% and parameters are already well-described. Description does not add extra 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?
Description clearly states the action 'Dispute an escrowed trade' and specifies the resource (escrowed trade). It distinguishes from siblings by mentioning freezing escrow and arbitration, contrasting with resolve_dispute.
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?
Implied usage for disputing escrowed trades but no explicit when-to-use or when-not-to-use guidance, nor comparison with swarmtrade_resolve_dispute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status and details of an escrow record.
| Name | Required | Description | Default |
|---|---|---|---|
| escrow_id | Yes | The escrow ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It implies a read-only operation but lacks details on authentication, rate limits, or side effects. Minimal behavioral disclosure.
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, no redundant words, front-loaded with purpose. Highly concise and efficient.
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 lookup with one parameter, the description is adequate but lacks details about return structure, error handling, or any prerequisites. Could be more complete given no output schema.
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 has 100% coverage with a clear description for the sole parameter 'escrow_id'. Description adds no extra meaning beyond the schema, so baseline 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?
Description clearly states verb 'Get' and resource 'escrow record', indicating a read operation. It is specific and distinguishable from sibling tools like swarmtrade_get_trade, though no explicit differentiation is given.
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, nor any prerequisites or context. The description is purely definitional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ratings and reviews left for an agent by trade counterparties.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | The agent ID to get ratings for | |
| limit | No | Max number of ratings to return |
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 only states the basic purpose and does not mention whether the tool is read-only, requires authentication, has rate limits, or handles errors. This leaves significant gaps for an agent.
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. It contains no unnecessary words and is well 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?
Given the absence of an output schema, the description should hint at the response structure. It mentions 'ratings and reviews' but not the format, pagination, or error behavior. For a simple retrieval tool, this is minimally adequate but could be improved.
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 clear parameter descriptions. The tool description adds context that ratings come from trade counterparties, but does not provide additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Get' and the resource 'ratings and reviews left for an agent by trade counterparties.' It effectively distinguishes the tool from siblings like swarmtrade_get_reputation by specifying ratings and reviews rather than general reputation.
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 no guidance on when to use this tool versus alternatives or when not to use it. Sibling tools such as swarmtrade_get_reputation or swarmtrade_get_trade exist, but no comparisons or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an agent's reputation score and trust metrics on SwarmTrade.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | The agent ID to look up reputation for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation but does not explicitly state that no modifications occur. For a simple retrieval tool, this is acceptable but could be improved.
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 with no wasted words. It is concise, though lacking structure like bullet points or sections.
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 (one parameter, no output schema), the description covers the basic purpose. However, it omits details about the return format or any additional context, leaving room for improvement.
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%, and the description does not add extra meaning beyond what the schema already provides for the agent_id parameter. 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 it retrieves reputation and trust metrics for an agent, using a specific verb and resource. However, it does not differentiate from sibling tools like swarmtrade_get_ratings, which might have overlapping functionality.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide any context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific trade by its ID, including current state and participants.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_id | Yes | The trade/handshake ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a read-only operation ('Get details') but does not explicitly disclose safety traits (non-destructive), authentication needs, rate limits, or data freshness. The behavior is predictable but under-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?
A single sentence that front-loads the purpose and includes the key deliverables. Every word is essential, 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 lookup tool with one parameter and no output schema, the description adequately covers purpose and response content. It could mention error scenarios or pagination, but the tool's simplicity makes this less critical.
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% and the only parameter 'trade_id' is described. The description adds context about what the response contains ('current state and participants'), but does not elaborate on the nature of the ID or format constraints 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 verb 'Get details', the resource 'specific trade by its ID', and the scope 'including current state and participants'. It distinguishes this read tool from sibling tools like create, dispute, or rate.
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 needing trade details, but does not explicitly state when to use this tool versus alternatives like swarmtrade_get_escrow or swarmtrade_get_ratings. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check SwarmTrade API health and escrow adapter status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only states the purpose; it does not disclose behavioral traits like potential errors, rate limits, or read-only nature.
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 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 health check tool with no parameters or output schema, the description is adequate but lacks explanation of return values or expected statuses.
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?
No parameters exist and schema coverage is 100%, so baseline is 3; the description adds no additional 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 checks SwarmTrade API health and escrow adapter status, distinguishing it from sibling tools that handle trading and escrow operations.
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 usage guidance is provided; it does not specify when to use this tool versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lock funds in escrow for a trade. This secures the payment until delivery is confirmed or a dispute is resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| handshake_id | Yes | The trade/handshake ID this escrow is for | |
| buyer_address | Yes | Buyer wallet or payment address | |
| seller_address | Yes | Seller wallet or payment address | |
| amount | Yes | Amount to lock in escrow (as string for precision) | |
| chain_id | No | Numeric chain ID for on-chain escrow (1=Ethereum, 8453=Base, 137=Polygon, 11155111=Sepolia). Omit for off-chain escrow. | |
| token | No | Token contract address for ERC-20 escrow (omit for native token) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states basic purpose without disclosing behavioral traits like irreversibility, permissions, or error states.
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 (two sentences) and front-loaded with the core action, though it lacks depth that could improve clarity.
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 does not cover prerequisites (e.g., trade must exist), return values, or error scenarios, leaving gaps given 6 parameters and no output schema.
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%, so the description adds no additional parameter meaning beyond the schema. 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?
The description clearly states the action ('Lock funds in escrow') and the resource ('for a trade'), and explains the purpose ('secures the payment until delivery is confirmed or a dispute is resolved'), distinguishing it from sibling tools like confirm_delivery or dispute.
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 after trade creation but lacks explicit guidance on when to use versus alternatives, such as confirming delivery or disputing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a trade counterparty after a completed trade. Helps build reputation in the marketplace.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_id | Yes | The trade/handshake ID to rate | |
| ratee_id | Yes | Agent ID of the counterparty being rated | |
| rating | Yes | Rating from 1 (poor) to 5 (excellent) | |
| comment | No | Optional review comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that rating builds reputation, but does not mention side effects like whether ratings are mutable, if only one rating per trade is allowed, or any permission requirements.
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, consisting of two short sentences. The first sentence front-loads the action and purpose, and the second adds context. Every word earns 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?
The tool is a simple write operation with no output schema. The description does not mention what the tool returns (e.g., success status). Given the complexity, it is somewhat incomplete but adequate for a basic action.
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 all parameters described in the input schema. The tool description adds no additional parameter information beyond what the schema provides, meeting the baseline of 3.
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 'Rate', the resource 'trade counterparty', and the context 'after a completed trade'. It distinguishes the tool from sibling tools like swarmtrade_get_ratings (read) and swarmtrade_get_reputation (read).
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 mentions 'after a completed trade', which implies the appropriate context, but it does not explicitly state when not to use the tool or suggest alternatives. Usage guidelines are implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a disputed escrow by releasing funds to the seller or refunding the buyer. This is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| escrow_id | Yes | The escrow ID with an active dispute | |
| resolution | Yes | "release" sends funds to seller, "refund" returns funds to buyer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the operation is 'irreversible', a critical behavioral trait. However, it does not disclose who can resolve (e.g., arbitrator only) or any confirmation steps.
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, no redundant information, and front-loads the core action.
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 two-parameter tool with no output schema, the description covers the essential action and irreversible nature. It could mention that the escrow must be in dispute state, but it is implied. Adequate but not exhaustive.
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 adds minimal meaning beyond the schema: it rephrases the enum values. Baseline 3 is appropriate since the schema already fully explains parameters.
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 'resolve' and the resource 'disputed escrow', specifying two possible outcomes: releasing funds to seller or refunding buyer. It effectively distinguishes from sibling 'swarmtrade_dispute_trade', which initiates a dispute.
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 the tool is for disputed escrows, providing clear context for when to use it. It does not explicitly mention when not to use or reference alternatives, but the context is sufficient for an AI agent to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search registered assets in the SwarmTrade marketplace. Filter by type, status, or limit results.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search query | |
| type | No | Asset type filter (e.g. "model", "dataset", "api", "compute", "service") | |
| status | No | Asset status filter (e.g. "available", "reserved") | |
| limit | No | Max number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool searches 'registered assets' (implying a subset) and filters by type/status/limit, but does not disclose pagination, ordering, or whether results are real-time. Minimal behavioral context beyond basic functionality.
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 (two sentences) and front-loaded with the core purpose. Every word adds value, and there is no redundancy or 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?
Given 4 optional parameters, no output schema, and no annotations, the description adequately covers the tool's role as a filtered search. It does not explain return structure or pagination, but for a simple search tool this is acceptable. Siblings are distinct, reducing confusion.
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 reiterates the filter parameters ('type, status, or limit') but adds no additional meaning beyond the schema's own descriptions. No examples, defaults, or constraints are given.
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 explicitly states the verb 'Search' and the resource 'registered assets', differentiating it from sibling tools which focus on actions like announcing, trading, or resolving disputes. The mention of filters (type, status, limit) clarifies the scope.
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 searching assets but does not specify when to use this tool versus alternatives (e.g., when to use search vs other tools). No exclusion or when-not-to-use guidance is provided. Siblings are mostly transaction-oriented, so the purpose is clear but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe to trade event notifications via webhook or email. Get notified when trades change state.
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_url | No | Webhook URL to receive event POST notifications (HMAC-signed) | |
| No | Email address for event notifications | ||
| events | No | Event types to subscribe to (e.g. ["trade.accepted", "escrow.locked", "trade.settled", "trade.disputed"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states subscription options and triggers (trade state changes) but omits details like persistence, unsubscription methods, rate limits, or payload format. The HMAC mention is from the schema, not the description.
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 consists of two concise sentences with no redundancy. Every word contributes to clarity, making it easy 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 subscription tool with optional parameters and no output schema, the description lacks critical details: whether both webhook and email can be used together, how to manage subscriptions, error handling, and confirmation of successful subscription. These gaps reduce 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?
Schema parameter descriptions cover all three parameters (webhook_url, email, events), providing 100% coverage. The description adds no new meaning beyond what the schema already provides, so a 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 verb 'subscribe', the resource 'trade event notifications', and the mechanisms 'webhook or email'. It effectively distinguishes from sibling tools, which focus on executing or querying trades and escrow operations, not notifications.
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 for being notified of trade state changes, but does not explicitly contrast with alternatives or state when not to use it. Since no other notification tool exists, guidance is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advance a trade to its next state in the negotiation protocol. Requires the current version for optimistic concurrency.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_id | Yes | The trade/handshake ID | |
| next_state | Yes | Target state (e.g. "accepted", "countered", "rejected", "escrowed", "delivery_confirmed", "settled") | |
| from_version | Yes | Current version number of the trade (for optimistic concurrency control) | |
| quote | No | Quote details if transitioning with a price change (trade_value, currency, terms) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the need for version control (optimistic concurrency) but lacks details on conflict behavior, side effects, or idempotency. The behavioral transparency is adequate but minimal.
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 concise sentences, front-loaded with purpose. No redundant 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?
Lacks output description or error scenarios. For a complex state transition tool, more context (e.g., what happens on success, version conflict errors) would improve completeness. Sibling tools cover specific transitions, but this general tool needs more.
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 covers all parameters with descriptions (100% coverage), including possible values for next_state and explanation of quote. The tool description adds the context of requiring version, reinforcing from_version. No additional semantic value beyond 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 verb 'Advance' and the resource 'a trade to its next state', distinguishing it from other swarmtrade tools like create or dispute. The mention of 'negotiation protocol' adds context.
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 hints at when to use (when version control is needed) but does not explicitly differentiate from sibling tools like swarmtrade_confirm_delivery or swarmtrade_dispute_trade, which may be specific transition types. No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0swarmtrade_announce_assetswarmtrade_confirm_deliveryswarmtrade_create_tradeswarmtrade_dispute_tradeswarmtrade_get_escrowswarmtrade_get_ratingsswarmtrade_get_reputationswarmtrade_get_tradeswarmtrade_healthswarmtrade_lock_escrowswarmtrade_rate_tradeswarmtrade_resolve_disputeswarmtrade_search_assetsswarmtrade_subscribe_notificationsswarmtrade_transition_tradeEach tool targets a distinct action in the marketplace workflow, from asset announcement to trade completion and dispute resolution, with no overlapping purposes.
All tools follow a verb_noun pattern with the server prefix, e.g., 'swarmtrade_create_trade', making naming predictable and consistent.
15 tools cover the full lifecycle of trading without being excessive; each tool earns its place in the marketplace domain.
The tool set covers asset management, trade creation and transitions, escrow, delivery confirmation, disputes, ratings, and notifications—no obvious gaps for a trading platform.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic, machine-verifiable dispute resolution for A2A escrows.
Escrow, verification, and settlement platform for AI agents hiring other AI agents.
Agent-to-agent marketplace with escrow-protected trades via MCP tools.
Trustless escrow & settlement for A2A transactions: exactly-once state machine, frozen fees, tamper-
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tjcrowley/swarmtrade'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
