Allows sending WhatsApp messages via the SMS tool.
MCP server for Suprsonic. Gives any AI agent dozens of capabilities through one connection.
SUPRSONIC_API_KEY=omk_your_key npx -y @suprsonic/mcpGet your API key at suprsonic.ai/app/apis.
Related MCP server: Adorbis AI MCP Server
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"suprsonic": {
"command": "npx",
"args": ["-y", "@suprsonic/mcp"],
"env": {
"SUPRSONIC_API_KEY": "omk_your_key"
}
}
}
}Add to .cursor/mcp.json or VS Code MCP config:
{
"suprsonic": {
"command": "npx",
"args": ["-y", "@suprsonic/mcp"],
"env": {
"SUPRSONIC_API_KEY": "omk_your_key"
}
}
}SUPRSONIC_API_KEY=omk_your_key npx -y @suprsonic/mcp --http --port 3100Then connect to http://localhost:3100/mcp.
Tool | What it does |
search | Search the web (AI synthesis, SERP, or both) |
scrape | Extract content from any URL as Markdown |
profiles | Find professional profiles by name or LinkedIn URL |
emails | Find professional email addresses |
images | Generate images from text prompts |
tts | Convert text to speech |
stt | Transcribe audio to text |
sms | Send SMS or WhatsApp messages |
documents | Extract structured data from URLs |
companies | Look up company data by domain |
email-verify | Check if an email is deliverable |
transcribe | Transcribe audio with speaker labels |
invoice-parse | Extract data from invoices |
subtitle | Generate SRT/VTT subtitles |
file-convert | Convert files between 200+ formats |
bg-remove | Remove image backgrounds |
screenshot | Capture webpage screenshots |
Every tool returns a unified response object:
{
"success": true,
"data": {
"results": [
{ "title": "OpenAI raises $6.6B", "url": "https://...", "snippet": "..." }
]
},
"error": null,
"metadata": {
"provider_used": "serperdev",
"providers_tried": ["serperdev"],
"response_time_ms": 1200,
"request_id": "req_abc123"
},
"credits_used": 1
}On failure, success is false and error contains the details (see below).
Error object structure (returned when success is false):
{
"type": "billing_error",
"title": "Insufficient credits",
"status": 402,
"detail": "Your account has 0 credits remaining. Add credits at suprsonic.ai/app/billing.",
"is_retriable": false,
"retry_after_seconds": null,
"error_category": "billing"
}Error categories: transient (retry safe), permanent (bad request), authentication (invalid key), billing (out of credits).
When using MCP, the AI agent receives the error in the tool response and can decide whether to retry based on is_retriable and retry_after_seconds.
Full API reference with all parameters and example responses: suprsonic.ai/apis
Remove the background from an image. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | URL to the image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions credit cost. Missing behavioral details like return format (URL? image data?), size limits, or supported image types.
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?
One concise sentence plus cost note—no wasted words. Appropriate for a simple tool, though slightly more detail could be accommodated without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., URL of processed image, success/failure info). It omits this completely, leaving agents uninformed about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with full description). The description adds credit cost info but no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('remove the background') and the resource ('image'), precisely distinguishing it from sibling tools like 'images' or 'file-convert'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., 'images' for editing tasks). The description only states what it does and the cost, but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up company data by domain. Returns industry, size, description, logo, brand colors. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain (e.g. stripe.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It adds the credit cost ('Cost: 3 credits') and lists return fields, which is useful. However, it does not disclose rate limits, error behavior, or access restrictions.
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 exactly two sentences, front-loaded with the key action, and every word is essential. No unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description covers the purpose, return data, and cost. It is nearly complete, though it could mention handling of unknown domains or pagination, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the domain parameter ('Company domain (e.g. stripe.com)'). The description adds no new information about the parameter beyond what the schema states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Look up company data by domain' (specific verb+resource) and lists the returned data fields. None of the sibling tools (e.g., profiles, search) perform the same task, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when company data is needed by domain) but does not explicitly state when not to use or provide alternatives. However, given the lack of overlapping siblings, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from a URL or text content using LLM analysis. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to scrape and extract from | |
| content | No | Pre-scraped text to extract from | |
| extraction_prompt | No | What to extract, in plain language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions cost of 3 credits but discloses no side effects, limitations, or operational details (e.g., whether it makes network calls, uses cache, or is idempotent). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with cost note, highly concise. Front-loaded with purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 parameters and no output schema; description lacks details on output format, parameter usage advice, and behavioral context. Incomplete for an extraction tool that could benefit from explaining what 'structured data' means or how to choose between url and content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description hints at 'url or text content' but does not elaborate on parameters beyond schema. No contradiction, but adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (extract), resource (structured data from URL or text), and method (LLM analysis). It distinguishes from siblings like 'scrape' which extracts raw HTML, and 'search' for web search, by specifying structured data extraction via LLM.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'scrape' or 'search'. No prerequisites or exclusions mentioned. Implies usage for structured data extraction, but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a professional email address by name and company domain. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| first_name | Yes | Person's first name | |
| last_name | Yes | Person's last name | |
| domain | Yes | Company domain (e.g. stripe.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the cost. It does not disclose whether the email is guaranteed to exist, what happens if not found, or any authorization or rate limit information. With no annotations, the description should carry this burden but fails to do so.
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, which is very concise. However, it front-loads the main action and cost, and there is no superfluous information. Slightly more structured format could improve readability.
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 annotations, the description is incomplete. It does not explain the return value (the actual email address), error handling, or any limitations. For a paid tool (2 credits), more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all three parameters (first_name, last_name, domain). The description adds context about the expected email type ('professional') and cost, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding a professional email address using first name, last name, and company domain. It distinguishes itself from the sibling 'email-verify' which likely verifies emails rather than finding them.
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., when to use 'email-verify' instead). No context about prerequisites or limitations is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an email address is deliverable. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a cost of 1 credit, but no annotations exist. It fails to disclose return format, error behavior, or whether an actual delivery attempt occurs. The agent cannot infer expected output from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence—and includes the key behavioral detail (credit cost). While it lacks structure, it is efficient and easy to parse.
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 omits crucial information: what the tool returns (e.g., boolean), error handling, and rate limits. It is incomplete for an agent to use 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?
Schema coverage is 100%, so the single parameter 'email' is already well-described in the schema. The description adds no additional context beyond the schema's documentation, achieving baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function—'Check if an email address is deliverable'—using a specific verb and resource. However, it does not differentiate from sibling tools like 'emails' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'emails'), nor are there any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a file between 200+ formats (PDF, DOCX, XLSX, images, etc.). Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | Yes | URL to source file | |
| source_format | Yes | Source format (e.g. docx, xlsx, html) | |
| target_format | No | Target format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. Description does not disclose behavioral traits such as file size limits, processing time, synchronous/asynchronous behavior, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and scope, second notes cost. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not explain return value format (e.g., download URL vs. binary). Missing key context for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline 3. Description adds 'Cost: 2 credits' but no additional semantic meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it converts files between 200+ formats with specific examples (PDF, DOCX, XLSX, images), distinguishing it from siblings like bg-remove or documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. siblings like documents or images. Only mentions cost, no when-not-to or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the image to generate | |
| aspect_ratio | No | 1:1, 16:9, 9:16, or 4:3 | 1:1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions the cost of 3 credits, which is good, but does not cover rate limits, safety filters, or response format, leaving significant gaps for an LLM evaluating tool usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no redundancy, and all information is front-loaded. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks output schema; the description does not explain what the tool returns (e.g., image URL or base64). Additionally, there is no mention of limitations or common errors, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully describes both parameters. The description adds no extra parameter information beyond the cost, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates an image from a text prompt, using a specific verb and resource. It distinguishes itself from sibling tools like bg-remove (image editing) and screenshot (capturing existing images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for text-to-image generation, but does not explicitly state when to use this tool versus alternatives like bg-remove or screenshot. No exclusions or context for choosing this tool are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured line items, totals, and dates from an invoice or receipt. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| document_url | Yes | URL to invoice PDF or image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions a cost. It fails to disclose whether the tool is read-only, if data is stored, or any authentication requirements. For a tool with no annotations, the description should cover these behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the tool's action and a cost disclaimer. Every word is functional with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), the description provides a basic understanding. However, it lacks detail on return format, supported file types beyond 'PDF or image', and error behavior, making it merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% with a clear description for 'document_url'. The tool description adds no additional semantic value for the parameter beyond what the schema already provides, meeting the baseline for high 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?
Description uses a specific verb 'Extract' and clearly identifies the resource (invoices or receipts) and the data extracted (line items, totals, dates). It distinguishes from siblings by being focused solely on document parsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for extracting data from invoices/receipts and mentions a cost constraint, but does not explicitly state when to use this tool versus alternatives (e.g., 'documents' or 'search'). No guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and enrich a professional profile by LinkedIn URL or name + company. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_url | No | LinkedIn profile URL (fastest path) | |
| first_name | No | Person's first name | |
| last_name | No | Person's last name | |
| company | No | Company name to narrow search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only states 'enrich' and a cost of 3 credits, but fails to disclose what enrichment entails, rate limits, authentication needs, or any side effects. This is insufficient for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loads both the purpose and usage methods without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not explain the return format or what data is included in the enrichment. Given the tool's complexity (finding and enriching profiles), this omission leaves the agent uncertain about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: 'fastest path' for linkedin_url and 'narrow search' for company, enhancing parameter understanding beyond the schema definitions.
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 finds and enriches a professional profile using LinkedIn URL or name+company, with a specific verb and resource, distinguishing it from broader tools like 'search' or 'scrape'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two usage paths (LinkedIn URL or name+company) but lacks guidance on when to prefer one over the other or when not to use this tool compared to siblings like 'search' or 'companies'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract content from any URL as Markdown. Auto-escalates from fast HTTP to JS rendering to stealth browser. Cost: fast 1 credit, standard 2 credits, thorough 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scrape | |
| mode | No | fast (1 credit, static HTML), standard (2 credits, JS rendering), thorough (5 credits, stealth + CAPTCHA) | standard |
| output | No | markdown, html, or raw_html | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: auto-escalation from fast HTTP to JS rendering to stealth browser, plus CAPTCHA handling. Cost structure is transparent. Missing details on rate limits, auth requirements, or error handling, but no annotations exist to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no wasted words. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, escalation, cost, and output format. Missing only minor operational details like rate limits or authentication, which are not required given the 3-parameter schema and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for url, mode, and output. Description adds value by explaining the auto-escalation and cost implications not fully captured in schema defaults.
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 'Extract content from any URL as Markdown,' with a specific verb and resource. It distinguishes the tool from siblings like screenshot or search by focusing on content extraction.
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?
Provides clear context on when to use each mode via cost levels (fast, standard, thorough) and auto-escalation behavior. However, no explicit exclusions or 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.
Capture a rendered screenshot of a webpage. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture | |
| full_page | No | Capture full scrollable page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the cost (1 credit) and implies page rendering, but it lacks details on side effects (e.g., page load delays, potential failures on dynamic content, or resource consumption). The transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, directly stating the core functionality and cost. There is no redundancy, and every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple screenshot tool with two parameters and no output schema, the description covers the essential purpose and cost. It could mention output format or error behavior, but it is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage, describing 'url' and 'full_page' clearly. The description adds no additional meaning beyond the schema, so it meets the baseline without providing extra insight into parameter usage or constraints.
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 captures a rendered screenshot of a webpage, which is a specific verb+resource. This distinguishes it from sibling tools like 'scrape' (text extraction) or 'images' (image processing), making the purpose unambiguous.
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 only mentions cost but provides no guidance on when to use this tool versus alternatives like 'scrape' for text or 'images' for manipulation. There is no context about prerequisites or optimal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web. Returns AI-synthesized answers, raw SERP results, or both. Cost: serp 1 credit, ai 2 credits, deep 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| mode | No | ai (2 credits, synthesized answer), serp (1 credit, raw links), or deep (3 credits, both) | ai |
| num_results | No | Max results for serp/deep mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return types (AI answer, SERP, both) and cost credits per mode, but lacks details on rate limits, caching, or permissions. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose. Each sentence provides essential info: first defines action and output types, second adds cost context. 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 3 parameters, the description covers modes, costs, and output types adequately. It could clarify 'AI-synthesized answers' but overall is complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining cost credits per mode and clarifying that num_results applies only to serp/deep modes. This goes beyond schema descriptions.
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 searches the web and returns AI-synthesized answers, raw SERP results, or both. The verb 'Search' and resource 'web' are specific, and the three modes are distinguished. This purpose is distinct from sibling tools like 'scrape' or 'images'.
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 (e.g., scrape, profiles). It explains mode selection but not use cases or prerequisites. Given many siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an SMS or WhatsApp message. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number in E.164 format (e.g. +1234567890) | |
| message | Yes | Message text | |
| channel | No | auto, sms, or whatsapp | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only adds cost information ('1 credit') but omits behavioral traits like rate limits, authentication requirements, error handling, or success/failure responses. Minimal disclosure beyond what the schema already offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively convey purpose and cost. No wasted words; front-loaded with essential information. Exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description missing behavioral details such as response format, error states, or asynchronous behavior. While simple, the tool lacks completeness for an agent to understand full implications of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters beyond what schema already states (phone format, message text, channel options).
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 uses specific verb 'Send' and resource 'SMS or WhatsApp message', clearly distinguishing it from siblings which handle emails, images, documents, etc. Cost info adds specificity.
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 clearly indicates the tool is for sending SMS or WhatsApp messages. It does not explicitly exclude alternatives but given sibling tools are for vastly different purposes, the context is clear. Lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe audio to text with timestamps. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_url | No | URL to audio file | |
| language | No | Language code | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description only discloses the cost (2 credits) and the inclusion of timestamps. It lacks information on side effects, limitations (e.g., file size, formats), or required permissions.
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 efficiently conveys the core function and cost, 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?
The description is adequate for a simple tool but lacks key details like supported audio formats, maximum duration, or output structure, especially since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter-specific details beyond the schema, not explaining, for example, that audio_url must be publicly accessible or the expected language code format.
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 transcribes audio to text with timestamps, using a specific verb and resource. However, it does not differentiate from sibling tools like 'transcribe' or 'subtitle'.
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, nor are there any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate SRT or VTT subtitles from audio or video. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_url | Yes | URL to audio or video file | |
| format | No | srt or vtt | srt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions cost (2 credits) but lacks other behavioral traits such as file size limits, supported formats, or processing behavior. With no annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and cost, 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?
For a simple tool with no output schema, the description is minimally adequate but lacks details on error handling, prerequisites, or differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters already described. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and resource 'SRT or VTT subtitles' from audio/video, distinguishing it from sibling tools like transcribe or stt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like transcribe or stt. No 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.
Transcribe audio or video with speaker labels and timestamps. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_url | Yes | URL to audio or video file | |
| speaker_labels | No | Enable speaker diarization |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions cost and output features (speaker labels, timestamps) but omits important behavioral details like processing latency, supported formats, file size limits, or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. Every word adds value, stating the core function, key features, and cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not specify output format, supported file types, maximum duration, or any constraints. Given the complexity of audio/video transcription, it leaves significant gaps for an agent to select and invoke 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 input schema has 100% description coverage for both parameters. The description adds no extra meaning beyond the schema; it only mentions speaker labels and timestamps (which are not parameters). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transcribes audio or video and includes speaker labels and timestamps. It distinguishes from potential siblings like 'stt' or 'subtitle' by specifying speaker diarization, but does not explicitly contrast with them.
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 such as 'stt' or 'subtitle'. The description mentions the credit cost but lacks context about prerequisites, alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text to speech audio. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to convert to speech | |
| voice_description | No | Describe the voice, e.g. 'calm professional female' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions cost (2 credits), but omits details on output format, authentication, rate limits, or whether the tool is destructive. This is insufficient for an agent to understand side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the core purpose. It is appropriately concise for a simple tool, though it could be slightly expanded without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and full schema coverage, the description lacks crucial context such as output type (e.g., audio file format), duration limits, error behavior, and integration expectations. This gaps hinder effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds no additional meaning beyond the schema's field descriptions, meeting the baseline but not enhancing understanding.
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 (convert text to speech) and the resource (audio). It is specific enough to distinguish from sibling tools like stt (speech to text) or transcribe, though it does not explicitly differentiate.
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 stt or transcribe. The description does not mention any prerequisites or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0bg-removecompaniesdocumentsemail-verifyemailsfile-convertimagesinvoice-parseprofilesscrapescreenshotsearchsmssttsubtitletranscribettsMost tools have distinct purposes, but there is some overlap among transcription tools (stt, transcribe, subtitle) which could cause confusion. Descriptions help differentiate, but the boundaries are not perfectly clear.
Tools use a consistent lowercase-with-hyphens pattern (e.g., bg-remove, email-verify). However, some are single-word abbreviations (sms, stt, tts), which is a minor deviation from the verb-noun pattern.
With 17 tools, the server covers a broad range of functionalities without being overwhelming. Each tool serves a specific purpose, and the count is appropriate for a general-purpose utility server.
The tool surface covers image, web, audio, data enrichment, and communication tasks reasonably well. Minor gaps exist (e.g., no image editing beyond background removal, no video processing), but the core workflows are addressed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
run any ai model. compose agents, stack knowledge, connect tools. one api, pay per run.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Pay-per-call agent superpowers: media/video gen, product demos, research, GTM, scraping, compute.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/O-mega-Enterprise/suprsonic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
