uniswap-tx-builder

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation5/5
Each tool targets a distinct Uniswap v3 action or query: mint, increase, collect, close, swap, wrap, plus state helpers. No functional overlap.
Naming Consistency5/5
All transaction builders follow 'build_' prefix, read-only helpers use 'get_' and 'plan_'. Consistent verb-noun pattern.
Tool Count5/5
8 tools is well-scoped for a Uniswap tx builder covering essential operations and state queries without bloat.
Completeness5/5
Covers full lifecycle: position creation (mint), modification (increase/collect), removal (close with optional burn), swapping, wrapping, and state queries. No obvious gaps.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 52 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the transaction is unsigned and payable, returns the tx and unsigned rlp, and recommends simulation with sender. It does not mention side effects (none expected for building an unsigned tx), which is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the primary purpose. It avoids fluff but could be slightly more structured by listing key parameters. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no output schema, no annotations), the description covers the main function and key behaviors but leaves several parameters unexplained. It is adequate but not fully complete; an agent would need additional context for chainId, deadline, and simulate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains amountWei, recipient (default to sender), and sender (for simulation), but omits chainId, deadline, and simulate. Critical parameters remain undocumented, leaving significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned transaction that wraps ETH into WETH via the Universal Router, specifying the verb 'build' and the resource. It distinguishes itself by mentioning the Universal Router allowlisting context, but does not explicitly contrast with sibling tools like build_swap or build_mint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: it works under UR-allowlisting policies and suggests passing sender for simulation. However, it lacks explicit guidance on when not to use this tool or clear differentiation from alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behavioral aspects: it builds an unsigned transaction (non-executing), removes liquidity, multicalls when needed, returns tx+unsigned rlp+read position, and explains burn and simulate options. It could mention that it does not execute the transaction, but 'unsigned' implies that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences plus a third for details. Main purpose is front-loaded, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return values (tx+rlp+read position). It covers the tool's core functionality, multicall behavior, and optional parameters. However, it omits descriptions for three parameters (chainId, recipient, positionId), leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for 2 of 5 parameters (burn, simulate) but does not describe chainId, recipient, or positionId beyond their existence. Since schema description coverage is 0%, the description should compensate more for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned transaction to remove all liquidity and collect everything from a Uniswap v3 position. This distinguishes it from sibling tools like build_collect (collect fees), build_increase (add liquidity), build_mint (create position), etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for closing a position but does not explicitly state when to use or not use this tool versus alternatives. It mentions optional parameters (burn, simulate) but no context for choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses that the transaction is unsigned, returns specific fields, and includes a simulate parameter to skip dry-run. It does not cover authorization or side effects, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the main purpose front-loaded. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format (to, data, value, chainId, rlp) and the simulate parameter. It covers key aspects, though it could mention permission requirements or state changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains recipient and simulate, but chainId and positionId are not described beyond their names, which are self-explanatory but lack constraints or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool builds an unsigned transaction to collect uncollected fees from a Uniswap v3 position, clearly distinguishing it from sibling tools like build_mint or build_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fee collection but lacks explicit guidance on when to use this tool versus alternatives or any prerequisites. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 tx is unsigned, amounts are decimal strings (wei), simulation is off by default because minting needs approvals and balances, and that passing simulate=true attempts simulation. It also mentions the return includes the tx and unsigned rlp. This provides significant behavioral context, though it could further describe potential reverts or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences. The first sentence states the primary purpose, and the second adds critical details about amounts, simulation, and return value. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description covers key behaviors (stale prices, simulation) and references get_pool_state. However, it omits details on tick lower/upper format, fee tier interpretation, token ordering, slippageBps meaning, and return structure beyond 'tx plus unsigned rlp'. This leaves the agent needing additional context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains amount0Desired and amount1Desired are decimal strings (wei) and simulate is a boolean. However, it does not describe token0, token1, fee, tickLower, tickUpper, recipient, chainId, or slippageBps. Many parameters remain undocumented, leaving gaps for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build an UNSIGNED tx that mints a new Uniswap v3 position.' It specifies the verb (build), resource (unsigned tx), and domain (Uniswap v3 mint). The title reinforces the purpose, and it differentiates from sibling tools like build_close, build_collect, and get_pool_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: amounts must be wei strings computed with get_pool_state right before minting to avoid stale prices. It also explains that simulation is off by default and when to pass simulate=true. However, it does not explicitly state when not to use this tool or compare it directly to alternatives like plan_position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that the transaction is unsigned, simulation is off by default, and prerequisites (approvals + balances) for simulation. Does not mention error handling or gas estimation, but key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with essential information: purpose, parameter format, default behavior, simulation option. No redundant or superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description covers purpose, parameter format, default slippage, simulation behavior, and return type (tx plus rlp). Could be more thorough on parameter constraints (e.g., positionId must exist, chainId must be valid), but overall sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that amount0Desired and amount1Desired are decimal strings in wei, and that slippageBps determines mins with a default. However, other parameters like chainId, positionId, and recipient are not described beyond the schema, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned transaction to add liquidity to an existing Uniswap v3 position. The verb 'build' and resource 'increase-liquidity' are specific and distinct from sibling tools like 'build_mint' or 'build_close'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: adds liquidity to an existing position, amounts in wei, mins derived from slippageBps with default 0.5%, simulation off by default. Lacks explicit comparison to siblings or when-not-to-use, but the purpose is sufficiently differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tx is unsigned, explains the swap mechanics (exact-in, single hop), wrap behavior, and simulation hint. Lacks details on gas implications or failure modes but is sufficiently transparent for common use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single dense paragraph that front-loads the main purpose. Every sentence adds value, but could benefit from structuring (e.g., separate sections for parameters, return value). Efficient for its information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no annotations, no output schema, the description provides a good overview of functionality and key parameters. It explains the core flow but lacks details on return format and some parameters. Still adequate for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains key parameters (amountInWei, tokenOut, fee, wrapWei, recipient, sender) and their roles. Missing explicit details for chainId, deadline, simulate, and amountOutMin, but the given context adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool builds an unsigned transaction for a WETH→token exact-in single-hop swap via Universal Router. It identifies the key resources (WETH, tokenOut, fee pool) and distinguishes from sibling tools by focusing on this specific swap operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use wrapWei vs not (native ETH vs WETH via Permit2) and mentions recipient defaults to sender. However, it does not explicitly compare against sibling tools or state when to choose this tool over alternatives like build_close or build_mint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly declares read-only ('builds no tx') and mentions error conditions. With no annotations, this carries the full burden acceptably.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with read-only indicator, each sentence adds value. Could be slightly more structured but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return fields, derived computations, and error condition. No output schema, but description hints sufficiently at what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains rangePct, balance0, balance1, tickLower, tickUpper and how they interact to compute amounts. Schema has 0% coverage, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns live pool state and lists specific fields (pool address, tick, etc.). It is distinct from sibling build tools which are transactional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to recompute before build_mint, giving a clear use case. Does not specify when not to use, but the read-only nature is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: read-only, reads decimals over RPC, returns aligned ticks and amounts, requires token0 < token1 by address, and does not compute optimal ratio. This provides comprehensive behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear label 'READ-ONLY helper' and providing all essential information in a few sentences without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description covers the main purpose, inputs, outputs, and constraints. It could be slightly more complete by explaining what happens when amounts are omitted or mentioning the RPC requirement, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden. It explains the meaning of priceLower, priceUpper as human price range, token0/token1 address constraint, and optional amount0/amount1. However, it does not describe fee or chainId explicitly beyond mentioning 'fee's tick spacing'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: a read-only helper that computes tick and amount parameters for a Uniswap V3 position from a human price range. It distinguishes itself from siblings like build_mint by noting it builds no transaction itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes it is a 'READ-ONLY helper (builds no tx)' and 'ready to feed into build_mint', providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![uniswap-tx-builder-mcp MCP server](https://glama.ai/mcp/servers/Yummybait-fin/uniswap-tx-builder-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Yummybait-fin/uniswap-tx-builder-mcp)

Score Badge

Copy to your README.md:

[![uniswap-tx-builder-mcp MCP server](https://glama.ai/mcp/servers/Yummybait-fin/uniswap-tx-builder-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Yummybait-fin/uniswap-tx-builder-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yummybait-fin/uniswap-tx-builder-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server