Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AutoEQ MCP Server Compare the Sennheiser HD 600 and the HiFiMAN Sundara"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
pip install autoeq-mcpAn MCP (Model Context Protocol) server that gives AI assistants access to the AutoEQ headphone equalization database — 8,800+ headphones and IEMs with parametric EQ settings, sound signature analysis, and Harman preference scores.
Ask your AI assistant things like:
"Get me the EQ settings for the HD650"
"Compare the HE400se and HD600"
"Recommend warm-sounding over-ear headphones"
"What are the top-ranked IEMs by Harman score?"
The server automatically analyzes frequency response measurements across 8 bands and classifies each headphone's sound signature (Neutral, Warm, Bright, Dark, V-shaped, etc.).
Related MCP server: Audio Analysis MCP Server
Tool | Description |
| Search by name, type (over-ear/in-ear/earbud), sound signature, or measurement source |
| Get full EQ profile — parametric EQ, fixed band EQ, per-band analysis with visual bars |
| Side-by-side comparison of two headphones across all frequency bands |
| Recommendations by preference (neutral, warm, bright, bass, vocal, fun, analytical) |
| Harman headphone listener preference score rankings |
| List all 61 available target curves (Harman, Diffuse Field, etc.) |
| Pull latest data from AutoEQ GitHub and rebuild the database |
# Sennheiser HD 650
- Source: oratory1990
- Type: over-ear
- Harman preference score: 84.0
- Sound signature: Neutral, Harman-like
## Per-band analysis (deviation from target, dB)
Sub-bass (20-60Hz): -3.2 dB [·······▓▓▓|··········] sub-bass lacking
Bass (60-250Hz): +0.8 dB [··········|··········] close to target
Mid (500-1kHz): -0.3 dB [··········|··········] close to target
Presence (2k-4kHz): +1.4 dB [··········|▓·········] detail emphasis
Air (8k-20kHz): -2.1 dB [········▓▓|··········] closed / lacking air
## Parametric EQ (Preamp: -6.5 dB)
# Type Fc (Hz) Q Gain (dB)
1 LowShelf 105 0.70 +6.5
2 Peaking 1800 1.20 -2.3
...# Install
pip install autoeq-mcp
# Initial database sync (clones AutoEQ repo + builds SQLite DB, ~20s)
autoeq-mcp --sync
# Add to Claude Code
claude mcp add autoeq_mcp -- autoeq-mcpFor Claude Desktop, add to your config file:
{
"mcpServers": {
"autoeq": {
"command": "autoeq-mcp"
}
}
}# Start SSE server
AUTOEQ_MCP_PORT=3008 autoeq-mcp --sse
# With allowed hosts for DNS rebinding protection
AUTOEQ_MCP_ALLOWED_HOSTS="your-domain.com,localhost" autoeq-mcp --ssegit clone https://github.com/verIdyia/autoeq-mcp
cd autoeq-mcp
pip install -e .
autoeq-mcp --syncAll configuration is via environment variables:
Variable | Default | Description |
|
| Directory for repo clone and SQLite DB |
|
| SSE server port |
|
| SSE server host |
| (none) | Comma-separated allowed hosts for SSE |
All headphone data comes from AutoEQ by Jaakko Pasanen (MIT License).
8,800+ headphone/IEM profiles
22 measurement sources (oratory1990, crinacle, Rtings, and more)
61 target curves (Harman 2018/2019, Diffuse Field, etc.)
2,300+ Harman preference scores
The database syncs from the AutoEQ GitHub repository. Run eq_sync or autoeq-mcp --sync to update.
The server analyzes each headphone's frequency response error (deviation from target) across 8 bands and classifies it:
Signature | Characteristics |
Neutral | All bands within ±2 dB of target |
Warm | Elevated bass, flat/recessed treble |
Bright | Elevated treble, flat/recessed bass |
Dark | Recessed treble |
V-shaped | Elevated bass + treble, recessed mids |
U-shaped | Elevated bass + treble |
Bass-heavy | Strongly elevated bass (>3 dB) |
Mid-forward | Elevated mids, flat bass/treble |
Harman-like | Total deviation < 1.5 dB average |
MIT — See LICENSE
Compare two headphones band-by-band with sound signature analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| name1 | Yes | First model name | |
| name2 | Yes | Second model name |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed-world scope. The description adds valuable context about the comparison methodology ('band-by-band with sound signature analysis'), which helps the agent understand what kind of analysis to expect beyond just a simple comparison.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core purpose without any fluff. It's front-loaded with the main action and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (comparison analysis), rich annotations (covering safety and behavior), and the presence of an output schema (which handles return values), the description is reasonably complete. It could be slightly improved by mentioning output format or comparison criteria, but the annotations and output schema compensate well.
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 description coverage is 100%, with both parameters clearly documented as model names. The description adds no additional parameter semantics beyond what the schema provides, such as format requirements or examples. With full schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Compare') and resource ('two headphones') with additional detail about the comparison method ('band-by-band with sound signature analysis'). It distinguishes from siblings like eq_profile, eq_ranking, and eq_recommend by focusing on direct comparison rather than profiling, ranking, or recommending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when comparing two specific headphone models, but provides no explicit guidance on when to use this tool versus alternatives like eq_search (which might find models) or eq_recommend (which suggests models). There's no mention of prerequisites, exclusions, or comparative advantages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed EQ profile for a headphone. Includes parametric EQ, fixed band EQ, and per-band sound analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Headphone/IEM model name (e.g., HIFIMAN HE400se, Sony WF-1000XM5) | |
| source | No | Measurement source (e.g., oratory1990). Empty = best scored source |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds value by specifying the types of EQ data included (parametric EQ, fixed band EQ, per-band sound analysis), which gives context about the return content. However, it does not disclose additional behavioral traits like rate limits, authentication needs, or error conditions beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and details the included components without any wasted words. It is appropriately sized for the tool's complexity and provides essential information in a structured manner.
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 tool's moderate complexity, rich annotations (readOnlyHint, idempotentHint, etc.), and the presence of an output schema, the description is largely complete. It specifies what data is retrieved, though it could benefit from mentioning when to use this tool over siblings. The output schema likely covers return values, reducing the need for detailed output explanation in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('name' and 'source') fully documented in the input schema. The description does not add any meaning beyond the schema, such as examples, constraints, or usage tips for parameters. Baseline score of 3 is appropriate since the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed EQ profile for a headphone', specifying it includes parametric EQ, fixed band EQ, and per-band sound analysis. However, it does not explicitly differentiate this tool from its six sibling tools (eq_compare, eq_ranking, eq_recommend, eq_search, eq_sync, eq_targets), which likely operate on similar data but for different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts for usage, nor does it reference sibling tools for comparison. This leaves the agent without direction on selecting the appropriate tool among the available options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get headphone rankings by Harman headphone listener preference score.
| Name | Required | Description | Default |
|---|---|---|---|
| form_factor | No | Type: over-ear, in-ear | over-ear |
| limit | No | Number of entries |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds no additional behavioral context (e.g., rate limits, authentication needs, or what 'ranking' entails beyond the score). It doesn't contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Get headphone rankings') and specifies the ranking method, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters), high schema coverage (100%), presence of annotations, and output schema, the description is reasonably complete. However, it lacks guidance on usage relative to siblings, which is a minor gap in context for an agent navigating multiple tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (form factor and limit). The description adds no parameter-specific semantics beyond what the schema provides, such as explaining the ranking criteria or default behaviors. Baseline 3 is appropriate given the schema's completeness.
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 specific action ('Get') and resource ('headphone rankings') with precise criteria ('by Harman headphone listener preference score'). It distinguishes this tool from siblings like eq_search or eq_recommend by focusing on ranking rather than searching or recommending.
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 like eq_search or eq_recommend. It lacks any mention of prerequisites, exclusions, or comparative context with sibling tools, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend headphones based on sound preference and type. Sorted by Harman preference score.
| Name | Required | Description | Default |
|---|---|---|---|
| preference | No | Sound preference: neutral, warm, bright, bass, vocal, analytical, fun. Or free text. | neutral |
| form_factor | No | Type: over-ear, in-ear, earbud | |
| limit | No | Number of recommendations |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior, so the description adds minimal behavioral context. It mentions sorting by Harman preference score, which is useful but doesn't detail rate limits, auth needs, or output format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's function, criteria, and sorting method without redundancy. It's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (read-only, idempotent), and the presence of an output schema, the description is largely complete. It covers the core purpose and sorting method, but could improve by briefly mentioning when to use versus siblings or output expectations.
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 fully documents parameters. The description adds marginal value by hinting at the purpose of 'preference' and 'form_factor' but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Recommend headphones') and the key criteria ('based on sound preference and type'), distinguishing it from siblings like eq_compare or eq_search by focusing on personalized recommendations. It also mentions the sorting method ('Sorted by Harman preference score'), adding 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 provides no guidance on when to use this tool versus alternatives like eq_search or eq_ranking, nor does it mention prerequisites or exclusions. It implies usage for headphone recommendations but lacks explicit context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the AutoEQ database for headphones/IEMs. Filter by name, type, sound signature, or measurement source.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term (model name, brand, etc.) | |
| form_factor | No | Type filter: over-ear, in-ear, earbud | |
| signature | No | Sound signature filter: Neutral, Warm, Bright, Dark, V-shaped, U-shaped, Bass-heavy, Mid-forward, Harman-like | |
| source | No | Measurement source filter: oratory1990, crinacle, Rtings, etc. | |
| limit | No | Max results (up to 50) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about the database scope (AutoEQ) and filterable attributes, though it doesn't mention rate limits, authentication needs, or pagination behavior beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and immediately lists the filterable attributes without any wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters), rich annotations, 100% schema coverage, and the presence of an output schema, the description is reasonably complete. It covers the purpose and filter scope adequately, though it could benefit from more explicit usage guidelines relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema. The description adds minimal value beyond the schema by listing filter types (name, type, sound signature, measurement source), but doesn't provide additional syntax, format details, or constraints beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search') and resource ('AutoEQ database for headphones/IEMs'), and distinguishes from siblings by specifying the search/filter functionality rather than comparison, profiling, ranking, recommendation, synchronization, or target-setting operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing filterable attributes (name, type, sound signature, measurement source), but doesn't explicitly state when to use this tool versus alternatives like eq_compare or eq_recommend, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull latest AutoEQ data from GitHub and rebuild the database. May take a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it discloses the time-consuming nature ('May take a few minutes') which isn't captured in annotations (idempotentHint=true, destructiveHint=false). Annotations already indicate this is a non-destructive, idempotent write operation, but the description enhances this with practical execution time information that helps the agent manage expectations.
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 perfectly efficient sentences: the first states the core action, the second provides crucial behavioral context about execution time. Zero wasted words, front-loaded with the primary purpose, and every sentence earns its place by adding distinct 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?
Given the tool has no parameters, comprehensive annotations covering safety and idempotency, and an output schema exists (so return values don't need description), the description provides adequate context. It covers what the tool does and key behavioral aspects (duration), though could potentially mention data sources more specifically or success indicators.
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool does operationally. No parameter information is needed or missing.
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 ('Pull latest AutoEQ data from GitHub and rebuild the database') with a specific resource ('AutoEQ data'). It distinguishes from siblings by focusing on database synchronization rather than comparison, profiling, ranking, recommendation, search, or targeting operations. However, it doesn't explicitly differentiate from potential similar tools like 'update_database' or 'refresh_cache' that might exist elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('May take a few minutes') suggesting it's for periodic updates or after new data is available, but provides no explicit guidance on when to use this versus alternatives like manual updates or other sync methods. It doesn't mention prerequisites, frequency recommendations, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available EQ target curves (Harman, Diffuse Field, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond annotations. Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed world. The description only specifies what is listed (EQ target curves with examples), which is useful but not rich in behavioral details like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function with no wasted words. It's front-loaded with the core action and includes helpful examples, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only operation) and the presence of annotations and an output schema, the description is reasonably complete. It specifies what is listed, though it could benefit from more context on how this differs from sibling tools to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the schema fully documents the input (none required). The description doesn't need to add parameter semantics, and it appropriately doesn't mention any, earning a baseline score of 4 for this context.
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 with the verb 'List' and resource 'EQ target curves', and provides examples of what those curves include (Harman, Diffuse Field, etc.). However, it doesn't explicitly differentiate this tool from its siblings like eq_search or eq_compare, which might also involve EQ targets in some way.
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 its siblings. It doesn't mention alternatives, prerequisites, or any context for usage, leaving the agent to infer based on the tool name alone.
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.
v0.1.0eq_compareeq_profileeq_rankingeq_recommendeq_searcheq_synceq_targetsScored across 7 tools
Each tool has a clearly distinct purpose: compare headphones, get EQ profiles, view rankings, get recommendations, search the database, sync data, and list target curves. There is no overlap in functionality, and the descriptions make the distinctions unambiguous.
All tool names follow a consistent 'eq_' prefix with a descriptive suffix (e.g., compare, profile, ranking), using snake_case uniformly. This pattern is predictable and enhances readability across the tool set.
With 7 tools, the server is well-scoped for its purpose of managing headphone EQ data and recommendations. Each tool serves a unique and necessary function, avoiding bloat while covering core operations like querying, syncing, and analyzing.
The tool set provides comprehensive coverage for the AutoEQ domain, including data retrieval (search, profile, targets), analysis (compare, ranking), recommendations, and maintenance (sync). There are no obvious gaps, enabling full agent workflows from discovery to implementation.
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
Search 2,000+ AI tools: pricing, alternatives, comparisons, and live, dead or acquired status.
AI visibility checks, software recommendations and tool comparisons from measured AI answer data
