suioracle
Server Details
SUIOracle - 12 Sui tools: objects, modules, validators, gas, Cetus DEX, NFTs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/suioracle
- GitHub Stars
- 0
- Server Listing
- SuiOracle
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.
Tool Definition Quality
Average 3.2/5 across 9 of 9 tools scored. Lowest: 2.4/5.
Each tool targets a distinct aspect of the Sui ecosystem: bridges, yields, DEX volume, objects, overview, protocol health, protocol list, stablecoin risk, and validators. Even overlapping concepts (TVL appears in overview, protocol list, and protocol health) are clearly differentiated by purpose.
All tools follow the consistent pattern 'sui_<descriptive_noun_phrase>' in snake_case, e.g., sui_bridge_flows, sui_defi_yields, sui_object_info. No mix of styles or irregular verbs.
With 9 tools, the server is well-scoped for its domain of Sui ecosystem data. Each tool earns its place, covering major areas without bloat.
The tool surface covers a broad range of Sui metrics: price, TVL, protocols, yields, DEX volume, bridges, objects, validators, and stablecoins. Minor gaps exist (e.g., no specific transaction or NFT tools), but the core analytics needs are met.
Available Tools
9 toolssui_bridge_flowsCInspect
Bridge flow monitoring for Sui
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Monitoring' vaguely implies read-only, but there is no explicit mention of behavior, side effects, permissions, or rate limits. This is insufficient.
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 short (four words), which is concise but lacks structure. It is not verbose, but it is also not a complete sentence or phrase that conveys sufficient 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?
For a parameter-free tool with no output schema, the description is the sole source of context. It fails to explain what data is returned, how to interpret results, or any usage details, making it 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?
There are zero parameters, so the baseline is 4 per rules. The description adds no parameter-specific details, but since none exist, the baseline holds.
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 identifies the tool's domain: bridge flow monitoring. It specifies the resource ('bridge flow') and the action ('monitoring'), which distinguishes it from sibling tools that focus on yields, volume, object info, etc.
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 implies usage for bridge flow data but does not specify exclusions or context, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_defi_yieldsCInspect
Compare DeFi yields across Sui protocols
| Name | Required | Description | Default |
|---|---|---|---|
| min_tvl_usd | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only says 'compare yields' without disclosing whether it reads data, makes external calls, or has any side effects. Behavioral traits beyond the basic purpose are absent.
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. For a simple tool with one parameter, it is appropriately sized, though it could front-load the parameter more clearly.
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 lack of output schema and minimal annotations, the description is incomplete. It does not specify return format, how yields are defined, or how the 'min_tvl_usd' filter affects results. More context is needed for an agent to use the tool correctly.
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 does not explain the 'min_tvl_usd' parameter, despite 0% schema coverage. The parameter name is somewhat self-explanatory, but the description fails to add meaning or usage details, which is required due to low schema coverage.
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 compares DeFi yields across Sui protocols, with a specific verb and resource. It distinguishes from sibling tools like sui_dex_volume or sui_protocol_health which focus on different metrics.
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 (e.g., for specific yield data vs other metrics). There is no mention of 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.
sui_dex_volumeBInspect
DEX volume across Sui exchanges
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the tool returns DEX volume. It fails to mention that it is a read-only query, lacks details on data freshness, rate limits, or any 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, efficient sentence with no unnecessary words, earning its place by clearly communicating the tool's 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?
Despite having no output schema, the description does not elaborate on return format, time period, or aggregation details, leaving the agent with insufficient context for interpreting results.
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 zero parameters, so the baseline is 4 per guidelines. The description adds no parameter-specific meaning, but that is acceptable as the schema is already fully covered (100% coverage).
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 'DEX volume across Sui exchanges' clearly specifies the resource (DEX volume) and scope (across Sui exchanges), distinguishing it from siblings like sui_defi_yields and sui_bridge_flows.
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 such as sui_overview or sui_defi_yields, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_object_infoCInspect
Get Sui object details by ID (type, owner, version)
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral aspects. It only states it is a read operation ('Get') but lacks details on idempotency, authentication, rate limits, error handling, or side effects. The minimal description does not compensate for missing 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 that is efficient and front-loaded with the key action. However, it is too brief, sacrificing completeness for conciseness, but it earns its place without unnecessary 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 the lack of output schema and low schema description coverage, the description should comprehensively explain the tool's behavior. It mentions the returned fields (type, owner, version) but omits response structure, optional parameters, error conditions, and performance characteristics, making it incomplete for an agent.
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 0% description coverage. The description adds 'by ID' but does not explain the required format, constraints, or examples for the object_id parameter. It provides no additional meaning beyond the parameter name.
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 (Get), the resource (Sui object details), and the specific fields returned (type, owner, version). It distinguishes the tool from siblings like sui_protocol_list or sui_dex_volume, which have different purposes.
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 only states what it does, not when it is appropriate or if there are prerequisites (e.g., object existence).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_overviewAInspect
Sui ecosystem overview: SUI price, TVL, protocol count, validators, transactions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists output fields without disclosing data freshness, caching, or error behavior. Limited transparency for a tool returning aggregated metrics.
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 clear sentence with zero redundancy. Front-loaded with purpose and lists key contents efficiently.
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 parameterless overview tool, the description adequately conveys its scope. No output schema, but the listed metrics give sufficient expectations. Could mention response format but not 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?
No parameters required, baseline 4. Description adds value by listing the included metric categories (price, TVL, etc.), clarifying what the overview contains.
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 provides a Sui ecosystem overview covering specific metrics (price, TVL, protocol count, validators, transactions). Distinct from sibling tools like sui_defi_yields, sui_dex_volume which focus on narrower domains.
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 usage guidance, but the broad overview nature and sibling specificity imply use for high-level snapshots. Lacks when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_protocol_healthBInspect
Protocol health: TVL, audits, risk grade (Cetus, NAVI, Scallop, Bluefin...)
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns TVL, audits, and risk grade, but does not disclose any behavioral traits such as authentication needs, rate limits, or whether it is a read-only operation.
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, well-front-loaded with the core purpose, and includes examples efficiently. It is appropriately sized with no 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?
Given the low complexity (1 parameter, no output schema, no annotations), the description covers the basic purpose and return types but lacks details on return format, error handling, or data recency. It is adequate but could be more thorough.
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 a single 'protocol' parameter with no description or enum, but the description compensates by listing example protocol names (Cetus, NAVI, Scallop, Bluefin), helping the agent understand valid inputs. With 0% schema coverage, this added value is significant.
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 specifies the tool retrieves protocol health metrics including TVL, audits, and risk grade, with examples of supported protocols. It is clear about the resource and action but does not explicitly distinguish from sibling tools like sui_protocol_list or sui_defi_yields.
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, no prerequisites, and no exclusions. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_protocol_listAInspect
All Sui DeFi protocols ranked by TVL
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description minimally implies a read-only operation but does not explicitly state it's non-destructive or mention caching or rate limits. Adequate for a simple list 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?
Single sentence, no wasted words, directly states purpose and key attribute (ranked by TVL).
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?
Describes return content (all protocols ranked by TVL) but missing output structure details. Sufficient given tool simplicity 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?
No parameters exist, and schema coverage is 100%. Description adds no parameter info but is not needed; baseline for 0 params is 4.
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 lists all Sui DeFi protocols ranked by TVL, distinguishing it from sibling tools like sui_defi_yields (yields) and sui_dex_volume (volume).
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 like sui_overview or sui_defi_yields; lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_stablecoin_riskCInspect
Stablecoin supply and risk on Sui
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states the subject. It does not mention data freshness, scope, limitations, or what 'risk' entails, leaving the agent with no behavioral context.
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 short sentence contains no fluff, but it could be slightly more structured. For a simple tool, it is appropriately concise.
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 vague description, the tool's output is underspecified. 'Supply and risk' is too broad; details like metrics or data scope are missing, making it incomplete for effective 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?
No parameters exist, and schema coverage is 100%. Baseline is 4 for zero parameters, but the description adds no value beyond the schema, merely stating the topic. A score of 3 reflects adequate but unhelpful semantics.
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 'Stablecoin supply and risk on Sui' indicates the tool's subject but lacks a verb specifying the action (e.g., get, list). It distinguishes from siblings like sui_defi_yields by focusing on stablecoins, but the purpose is only moderately clear.
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 sui_protocol_health or sui_defi_yields. There is no context for deciding between these related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sui_validator_infoAInspect
Validator overview: count, stake, top 10, commission rates, APY
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists output fields (count, stake, etc.) but does not disclose behavioral traits such as data freshness, query scope, or whether the tool is read-only. Adequate but lacks depth.
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 front-loads the purpose. No 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?
Given no output schema and no annotations, the description provides the main output fields but lacks context on data source, update frequency, or clear differentiation from sibling tools like sui_overview.
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 (0 params, 100% schema coverage). The description is not required to add parameter info, and the baseline for 0 params is 4.
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 specifies the tool provides a validator overview including count, stake, top 10, commission rates, and APY. This clearly identifies the resource and differentiates it from siblings like sui_overview or sui_defi_yields.
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 given on when to use this tool versus alternatives. The description does not mention when-not to use it or suggest sibling tools for more specific queries.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.