Surf MCP Server

Official

by asksurf-ai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Each top-level tool has a distinct domain prefix (dex, exchange, market, prediction_market, etc.), but there is some overlap: surf_dex and surf_hyperliquid both provide DEX data, and surf_market vs surf_exchange could be confused for price/derivatives data. Descriptions generally help clarify the boundaries.
Naming Consistency5/5
All tools follow the consistent 'surf_<domain>' naming pattern, and subcommands use lowercase hyphenated names. The convention is uniform across the entire set, making it predictable and easy to navigate.
Tool Count5/5
15 tools is within the ideal 3-15 range, and each tool represents a coherent data domain (market, wallet, token, onchain, etc.). The count feels well-scoped for the server's broad crypto data aggregation purpose.
Completeness4/5
The tool surface covers a wide range of crypto data needs: market, exchange, DEX, prediction markets, onchain, wallet, token, project, fund, news, search, and web. Minor gaps exist (e.g., surf_dex only offers OHLCV, surf_x only fetches tweets by ID), but these are partial gaps within subdomains rather than severe dead ends.
Average 4/5 across 15 of 15 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool's safety profile is known. The description adds useful context such as converting to 'LLM-friendly markdown' and targeting 'crypto-related' content, which is helpful. However, it does not disclose potential limitations, rate limits, or behavior beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably sized and structured with a purpose statement and a Commands section. However, it redundantly states 'Fetch and search web content' immediately before detailing the fetch command, and the search functionality is not properly documented. The structure could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema coverage and no output schema, the description carries the full burden. It details fetch parameters but omits search parameters, return format, error behavior, and any usage caveats. The tool's complexity (multiple operations) is not fully covered, leaving gaps for the agent.
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 input schema has no parameter descriptions (coverage 0%), and the description only lists parameter names (url*, target_selector, etc.) without explaining their meaning or format. For example, 'target_selector' is left ambiguous. The description partially compensates by listing names, but it lacks the depth needed for confident invocation.
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 'Fetch and search web content' and 'Retrieve any URL and convert it to clean, LLM-friendly markdown'. It distinguishes itself from sibling tools by focusing on general web data rather than a specific domain (e.g., surf_dex, surf_token). The verb+resource combination is specific enough, though 'web data' is broad.
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 opening line 'Use this when the user needs web data from Surf' provides a clear usage context. However, it does not explicitly mention when not to use this tool or alternatives like surf_news or surf_token. The command list gives some guidance (fetch for web page fetching) but lacks a search command, despite search being mentioned in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds that it retrieves by numeric post ID and returns author details, but does not disclose other behaviors like pagination or error handling. This is adequate but not rich.
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 and front-loaded with the usage guideline. The command listing is terse but straightforward, and every part earns its place. No unnecessary 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?
For a simple read-only tool with one command and good annotations, the description covers the core purpose. However, it lacks details on how to pass multiple IDs, the exact response format, and any limitations. The missing output schema and vague parameter explanation leave some gaps, but overall it is adequate.
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 description coverage is 0%, so the description must compensate. It mentions 'params: ids* (string)' which gives the parameter name and type, but it is ambiguous whether ids is a single string or an array, and it does not explain the structure of the params object relative to the command. The description adds some meaning but not enough for full clarity.
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 retrieves X posts and author details by numeric post ID, which is a specific verb+resource+scope. It distinguishes from sibling tools by focusing on X/Twitter data, though it does not explicitly name alternatives.
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 opens with 'Use this when the user needs x data from Surf', providing a clear context for when to use the tool. It does not mention exclusions or alternatives, but the context is sufficient for a simple read-only tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the command structure and indicates the tool returns OHLCV price data. It does not disclose additional behaviors such as limitations, prerequisites, or response format, but given the annotations, this level is adequate.
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 compact and well-structured: a single use case sentence followed by a parameter listing for the one command. Every element contributes to the agent's understanding, with no redundant or filler 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?
For a simple read-only tool with a single command, the description covers purpose, command, and parameter list adequately. It lacks explicit return value structure, but since there is no output schema, the mention of 'OHLCV Price' gives a hint. Minor gaps in parameter semantics and output format prevent a higher score.
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?
The schema itself has zero descriptions and an unconstrained 'params' object, so the description must compensate. It lists all parameters with types and required markers: chain*, address*, interval, time_range, from, to. This is essential context beyond the empty schema. However, it doesn't explain the meaning or format of each parameter (e.g., valid interval values), so it's not fully rich.
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 'Use this when the user needs dex data from Surf' and names the command 'token-price' with its purpose 'DEX Token OHLCV Price.' This identifies the tool as a DEX data retrieval tool. It distinguishes from siblings by the specific 'dex data' domain, though it does not explicitly name sibling tools.
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 a clear usage context: 'when the user needs dex data from Surf.' However, it does not mention when not to use it or suggest alternative tools like surf_exchange or surf_market for other data types, so exclusions and alternatives are absent.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating the tool reads articles, fetches full content, and searches sources, which is consistent and adds value without contradicting the annotations.
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 efficiently structured with a usage line, a capability summary, and a command list. It is scannable and each line adds operational detail without unnecessary fluff.
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?
The description covers the commands and their parameters but lacks details like date formats, default values, or response structure. Since there is no output schema, this is a notable gap, though the description provides a solid baseline for a read-only news tool.
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?
The input schema has 0% coverage for the 'params' object, but the description compensates by listing each command's parameters with types and a few enum values (e.g., sort_by: recency, trending). It also marks id* as required and includes limit/offset for pagination, which is a good compensation.
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 identifies the tool as providing crypto news data, with capabilities to browse articles, read full content, and search by keyword. It distinguishes itself from sibling tools by its focus on news, though it doesn't explicitly name alternatives.
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?
It starts with 'Use this when the user needs news data from Surf,' which is an explicit usage signal. It also differentiates commands by listing 'detail' and 'feed' with their respective parameters, providing operational guidance, though no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about the tool's scope and lists commands, but it does not disclose additional behaviors such as rate limits, pagination, response shapes, or error handling. It does not contradict the annotations, so a mid-level score is appropriate.
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 long but well-structured with a front-loaded purpose sentence and a consistent, readable format for the 15 commands. Each line adds necessary details (params, enums, required markers), though some redundancy exists (e.g., repeating 'string' everywhere). The length is justified by the tool's complexity, and it earns its place without being wasteful.
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 large number of subcommands (15) and the absence of both an output schema and detailed schema properties, the description provides a solid overview of capabilities and complete parameter lists. However, it does not describe the return format or data structure for individual commands, which is a notable gap since there is no output schema to clarify this. The overview partially addresses this, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic 'params' object with no properties, leaving 0% coverage. The description compensates thoroughly by listing every command with parameter names, required indicators (asterisk), enum values, and types. This is essential, high-value documentation that the schema completely lacks, making the tool usable.
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 opens with an explicit purpose: 'Use this when the user needs market data from Surf,' followed by a detailed enumeration of the data types it covers (rankings, derivatives, ETF flows, liquidations, technical indicators, on-chain metrics, Fear & Greed). This is a specific verb+resource+scope statement that clearly differentiates the tool from sibling tools focused on other domains like DEX, news, or wallets.
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 opening line provides general context ('Use this when the user needs market data'), but it does not explicitly mention when NOT to use it or suggest alternatives. Sibling tools such as surf_onchain, surf_exchange, and surf_token overlap in areas like on-chain indicators and exchange data, and the description does not clarify boundaries. The guidance is 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, etc.) offer minimal safety context. The description adds command-level detail but does not disclose potential side effects of SQL job submission or rate limits, nor does it specify that queries are read-only. This is adequate but not exemplary.
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 well-organized with a summary paragraph and a structured list of commands. It is relatively long due to 12 commands, but each line is terse and front-loaded with the usage directive. The structure aids quick scanning.
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 tool's complexity (12 commands) and lack of output schema, the description covers the command inventory and parameter names/types but omits parameter meanings and return values. This leaves gaps for successful invocation without further research.
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?
The input schema is generic (command + params object), so the description carries the burden. It lists every command's parameters with types and some enums (e.g., chain options for dex-activity and gas-price), which is valuable. Yet many parameters like $schema or source are left unexplained, reducing full semantic clarity.
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 opens with 'Use this when the user needs onchain data from Surf' and elaborates with concrete capabilities like transaction hash lookups, gas prices, and SQL queries across Ethereum, Base, Solana, and more. This clearly distinguishes it from sibling tools focused on specific protocols or markets.
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?
It provides a clear 'Use this when' directive for onchain data needs and enumerates subcommands (e.g., gas-price, tx) for specific use cases. However, it does not explicitly contrast with sibling tools or state when not to use this tool, so it lacks the explicit when-not guidance that would merit a 5.
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?
Annotations already mark the tool as read-only and non-destructive. The description adds behavioral context by detailing the command-dispatch structure, listing subcommands, and flagging 'pulse' as deprecated. It does not cover pagination behavior or auth requirements, but adds meaningful value beyond annotations.
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 front-loaded with purpose and then provides a structured command reference. Each command is limited to one line with its parameters, and the deprecated command is clearly marked. It is longer than minimal but appropriately sized for a multi-command dispatcher.
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 (command enum, free-form params, no output schema), the description provides enough command-specific detail, including parameter hints and deprecation, to be usable. It stops short of explaining return values or parameter semantics, but is reasonably complete for tool selection and basic invocation.
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?
The input schema only defines a generic 'params' object, giving 0% coverage. The description compensates by listing parameters for each command, including types and enums (e.g., metric, lang). However, it does not explain the meaning of ambiguous parameters like 'q' or 'fields'.
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 this tool is for retrieving project data from Surf, covering aggregated profiles, funding, tokenomics, and DeFi metrics. It distinguishes itself from the sibling tools by focusing on 'project data' and 'DeFi protocol metrics', but it does not explicitly name alternatives.
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?
It opens with 'Use this when the user needs project data from Surf' and then enumerates commands for different project-related queries. It gives clear context for when to use the tool but does not explicitly state when not to use it or name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds scope (what data is accessible) but does not disclose additional behavioral aspects such as rate limits, pagination behavior, data freshness, or any side effects. It is consistent with annotations, so no contradiction.
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 long but well-structured as a command reference with consistent formatting and a clear opening purpose statement. Each command line provides necessary parameter information, so length is justified by the tool's 23 subcommands. It is not overly verbose for the complexity it covers.
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 (23 commands) and minimal schema/annotations, the description provides substantial parameter details and clearly enumerates all available operations. It lacks examples of response structures or workflow guidance, but the command names and parameter lists suffice for basic selection and invocation. The absence of an output schema means return values are not required to be explained.
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?
The input schema only has a generic 'params' object and a command enum, providing zero parameter-level documentation. The description compensates by listing each command's expected parameters with types and allowed enums (e.g., platform, time_range, sort_by), and marks required parameters with *, enabling an agent to construct valid calls despite the schema being underspecified.
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 identifies the tool as providing prediction market data for Polymarket and Kalshi, with specific actions like browsing events/markets, viewing prices/odds, and analyzing volume/open interest. This distinguishes it from sibling tools focused on other domains (e.g., surf_dex, surf_exchange) by naming a specific resource and scope.
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 opening sentence explicitly states 'Use this when the user needs prediction market data from Surf,' providing a clear usage context. However, it does not directly mention alternatives or when not to use the tool, though the command list internally guides between Polymarket and Kalshi subcommands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the multi-command structure and per-command parameter details but does not provide additional behavioral context like pagination behavior, rate limits, or return format.
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 opens with a concise directive, then presents a structured command list. It is somewhat long due to the many subcommands, but the list format is efficient and each line carries necessary parameter information. Front-loading of the core purpose is good.
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?
For a multi-command search tool with no output schema, the description provides substantial detail: all commands, their parameters, and enums. However, it lacks information about return values, pagination defaults, or constraints like how 'params' object is interpreted. Given the complexity, it is fairly complete but not exhaustive.
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?
The schema only defines 'command' and a generic 'params' object, so description coverage is 0%. The description compensates by listing every command's specific parameters, including required markers (q*) and enums for several fields. It adds significant meaning beyond the schema, though it doesn't explain what each parameter semantically represents.
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 performs unified search across Surf's data universe, listing specific categories (crypto projects, news, wallets, etc.). This distinguishes it from domain-specific siblings like surf_news or surf_token.
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?
It explicitly says 'Use this when the user needs search data from Surf' and enumerates search types, giving clear context. However, it does not explicitly mention when not to use it or compare to specific sibling tools, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and non-destructive. The description adds valuable detail about what operations can be performed (holders, transfers, DEX trades, tokenomics), but does not disclose anything beyond that, such as rate limits, pagination behavior, or response format. It adds some context but not deep behavioral transparency.
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 long but well-structured with command headings and parameter lists, making it scannable. It front-loads the main use case and each section serves a purpose. Slight overhead from repeating chain lists across commands, but overall efficient for the tool's complexity.
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?
With no output schema, the description covers input parameters thoroughly but offers little about what outputs look like or how results are returned. It mentions the kind of data (top holders, transfer stats) but not structure or pagination details. For a multi-command tool, this leaves some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'command' and 'params' as generic objects with zero coverage. The description compensates fully by listing every available command and its parameters, including required markers, allowed enums for chain, direction, metric, and time_range, plus types. This is far beyond what the schema provides, making it highly informative.
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 purpose: 'Use this when the user needs token data from Surf.' It specifies exact capabilities like analyzing token holders, transfers, DEX trades, and token unlock schedules. This distinguishes it from sibling tools that focus on DEX, wallet, or market data.
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 an explicit 'when to use' statement in the first line. It does not explicitly mention when not to use it or name alternative tools, but the specific subcommands and scope make usage context clear. Lacks exclusionary guidance, hence not a 5.
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?
The description goes beyond the annotations by detailing sub-commands and their parameters, revealing that the tool supports three distinct query modes (detail, portfolio, ranking) with specific filter and sort options. This is meaningful behavioral context not captured by the readOnlyHint.
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 well-structured with a lead-in sentence and a compact command breakdown. It is longer than some but every sentence contributes to understanding tool usage. The command list format is efficient and scannable.
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 multi-command complexity and absence of an output schema, the description provides solid coverage of commands and parameters. It does not detail return values, but the command names and parameter lists give sufficient context for an agent to select and invoke the tool.
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?
With schema coverage at 0%, the description carries the full burden of documenting parameters. It lists all sub-command parameters, types, enums, and defaults (e.g., is_lead, sort_by, order). However, some parameters like 'q' and 'id' lack semantic explanation, leaving minor 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?
The description clearly states what the tool does: 'Use this when the user needs fund data from Surf.' It then enumerates specific capabilities (fund profiles, portfolios, rankings), distinguishing it from sibling tools focused on DEX, tokens, etc.
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 opens with an explicit when-to-use statement: 'Use this when the user needs fund data from Surf.' It does not mention exclusions or alternatives, but the sibling list and domain-specific language make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read behavior is known. The description adds a comprehensive command reference but does not disclose additional behavioral traits such as data freshness, pagination handling, authentication requirements, or any potential rate limits. It does not contradict the annotations.
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 efficiently structured as a command list with each line showing the command name and its parameters. The purpose sentence is front-loaded, and there is no filler. Despite its length, every entry earns its place by providing essential invocation details for the tool's many subcommands.
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?
The description covers all ten commands and their parameter lists, providing a complete map of the tool's capabilities. However, it does not explicitly state how the top-level params object should be populated for each command, nor does it describe the return value structure. Since there is no output schema, a brief note on response format would improve completeness, but the command names and parameter lists make the intended calls reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a command enum and a free-form params object, providing zero documentation for nested parameters. The description compensates fully by listing every command's parameters, marking required ones with an asterisk, and specifying enums for many fields (e.g., interval, order, time_range). It also disambiguates formats (e.g., to_ms integer) and optionality, adding substantial meaning beyond the schema.
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 opening sentence clearly states 'Use this when the user needs hyperliquid data from Surf', specifying the exact resource and action. It then enumerates all available commands, making the tool's scope unmistakable and distinguishing it from sibling tools that target other data domains (e.g., surf_dex, surf_token).
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 gives a clear 'Use this when...' context, and the command list provides intra-tool guidance on which command to invoke for specific data needs (e.g., account, candles, trades). However, it does not explicitly mention when not to use this tool or point to alternatives like surf_onchain for other types of data.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to cover safety. It adds context about real-time data and available data types (tickers, order books, funding rates), which is valuable. However, it doesn't discuss rate limits, pagination, or authentication, but given the annotations, this is not a major gap.
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 front-loaded with the purpose statement and then provides a structured, scannable list of commands with their parameters. While the list is long, it is efficient and each line serves a purpose; no redundant 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?
This is a multi-command tool with many parameters and no output schema. The description lists all commands with brief descriptions and parameter details, which is sufficient for an agent to select and call the right command. It doesn't fully explain return formats, but the command names are self-explanatory and no output schema is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a 'command' enum and an opaque 'params' object with no properties. The description compensates fully by listing each command's parameters with types and enums (e.g., exchange, interval, limit), providing essential information the schema omits.
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 begins with 'Use this when the user needs exchange data from Surf' and then details specific data types (ticker prices, order book, OHLCV, funding rates) available from major exchanges. This clearly specifies the tool's function and distinguishes it from sibling tools focused on DEX, prediction markets, etc.
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?
It gives a clear context: 'Use this when the user needs exchange data from Surf' and lists exchange names, but it does not explicitly exclude alternatives or mention when to use other Surf tools like surf_dex. Thus it has clear context but no explicit exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description goes beyond annotations by listing the four commands (detail, projects, token-of-the-day, token-of-week) and the data types included (latest price, price-change, dimension scores, compact signals, AI summaries). It does not mention pagination or default time_range values, but the command structure adds real value.
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 front-loaded with the primary use case, followed by a succinct command reference. The command list earns its place due to the multi-command structure. There is no redundant or filler content, making it appropriately sized for the tool's complexity.
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?
There is no output schema, so the description must convey what the tool returns. It provides a high-level overview (signal cards with latest price, price-change, dimension scores, AI summaries) and enumerates commands with parameters. However, it does not detail per-command output differences or response formats, leaving a minor gap for a 4-command tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only provides a generic 'params' object. The description fully compensates by listing each command's parameters explicitly with types and enums (e.g., id, project_slug, time_range with [24h, 7d], limit, offset). This gives the agent complete parameter semantics that the schema alone would not convey.
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 states a specific purpose: 'Use this when the user needs signal data from Surf' and elaborates with 'Explore ranked project signal score snapshots...'. The verb 'explore' and resource 'signal data' distinguish it clearly from sibling tools like surf_dex or surf_news, which focus on other domains.
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?
There is an explicit trigger condition: 'Use this when the user needs signal data from Surf'. This gives clear context for when to use the tool. However, it does not mention alternatives or when not to use it, so it stops short of a full when/when-not/alternatives guidance.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context such as the ability to inspect 'any wallet' across multiple chains, view token balances, NFTs, transaction logs, and net worth trends. It doesn't mention rate limits, response pagination, or authentication, but those are less critical given the annotations.
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 efficiently structured: a brief front-loaded purpose statement followed by a compact command list with parameters. Every sentence earns its place, and the formatting is consistent and scannable. It provides comprehensive information without unnecessary prose.
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?
With no output schema, the description adequately outlines what data is available (balances, NFTs, labels, history, protocols, net worth) and defines all commands. It lacks explicit return value specifications per command, but the overview is sufficient for most usage. Given the complexity of the tool, the description is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (only command and free-form params), and schema coverage is 0%. The description compensates by providing detailed parameter lists for each command, including enums for chain, sort_by, order, and flow, and specifying required fields (address*). This adds significant meaning beyond the schema and enables proper tool invocation.
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 with a specific verb ('Inspect any wallet') and resource ('wallet data from Surf'), and the list of commands (detail, history, etc.) enriches the purpose. It distinguishes from sibling tools by focusing specifically on wallet data across chains and DeFi positions.
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 states when to use it ('Use this when the user needs wallet data from Surf') and covers a range of sub-uses (balances, NFTs, history, protocols). It doesn't explicitly name alternatives or exclusions, but the context is clear and the commands provide guidance on selecting the right sub-command.
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:

[![surf-mcp MCP server](https://glama.ai/mcp/servers/asksurf-ai/surf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/asksurf-ai/surf-mcp)

Score Badge

Copy to your README.md:

[![surf-mcp MCP server](https://glama.ai/mcp/servers/asksurf-ai/surf-mcp/badges/score.svg)](https://glama.ai/mcp/servers/asksurf-ai/surf-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/asksurf-ai/surf-mcp'

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