Algolia Productivity

by io.github.algolia

Overview Discussions Admin

Server Details

Connect LLM tools to your Algolia account with user-scoped access for internal workflows.

Ownership verified

Status: Healthy
Uptime: 71.3% over 59 days
OAuth: Works in Glama
Last Tested: 2026-10-15 02:07
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-05 19:30 across 4 tools

Disambiguation5/5

The three Algolia operation tools form a clear discover→describe→call pipeline with distinct roles, and knowledge_search is cleanly separated as a documentation-lookup tool versus account-data tools. No two tools could plausibly be confused for one another.

Naming Consistency4/5

All names share an algolia_ prefix in snake_case and are verb-led (discover, describe, call, knowledge), which is predictable and readable. Minor deviations like call_read_tool (compound verb) and knowledge_search vs the *_tool suffix pattern keep it from perfect uniformity.

Tool Count5/5

Four tools is well-scoped for a discovery-driven meta server: three cover the operation lifecycle and one covers documentation. Each tool earns its place with no redundancy.

Completeness3/5

Read operations are covered via algolia_call_read_tool, but describe_tool surfaces operations with a read/write effect and there is no corresponding write/execute tool, so any write operation is a dead end. The read-only surface is coherent but leaves an obvious gap for mutation workflows.

Available Tools

4 tools

algolia_call_read_toolCall Algolia Read ToolA

Read-only

Inspect

Run one read-only Algolia operation. Use this after algolia_discover_tools, and usually after algolia_describe_tool, when the selected operation has effect read. Pass the operationName and arguments exactly as described. Returns that operation's result.

ParametersJSON Schema

Name	Required	Description
`arguments`	Yes	Arguments for the Algolia operation
`userIntent`	No	How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.
`operationName`	Yes	Name of the Algolia read operation to execute. Call algolia_discover_tools to find available operation names; call algolia_describe_tool to inspect a specific operation's input schema before calling it here.
`originalQuery`	No	The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description restates read-only and adds the sequencing gate, but says nothing about behavior on an invalid operationName, error surfacing, or rate limits, so it adds only modest value beyond the structured fields.

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?

Four short sentences, no waste, with the primary action front-loaded and the call chain following. Every sentence earns its place.

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 generic dispatch tool with no output schema, the description gives the prerequisite chain and return expectation ('Returns that operation's result'). Adequate; only minor gaps remain around error handling and how to recover when the chosen operation is not read-effect.

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 100%, so the schema already documents all four parameters, including operationName's pointer to discover/describe and userIntent/originalQuery. 'Pass the operationName and arguments exactly as described' reinforces provenance but adds no syntax or format detail beyond the schema.

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?

States a specific verb+resource: 'Run one read-only Algolia operation.' The read-only scoping plus the meta-tool framing cleanly separates it from algolia_discover_tools and algolia_describe_tool, which are named in the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit sequencing: 'Use this after algolia_discover_tools, and usually after algolia_describe_tool, when the selected operation has effect read.' Both the prerequisite tool calls and the gating condition (effect=read) are stated, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

algolia_describe_toolDescribe Algolia ToolA

Read-only

Inspect

Inspect one Algolia operation returned by algolia_discover_tools before calling it. Use this to get the exact input schema, read/write effect, domain, title, and description for a specific operation name.

ParametersJSON Schema

Name	Required	Description
`userIntent`	No	How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.
`operationName`	Yes	Name of the Algolia operation to describe. Call algolia_discover_tools first to find available operation names.
`originalQuery`	No	The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, non-destructive, non-open-world behavior, so the bar is lowered. The description still adds value by enumerating what the tool surfaces (read/write effect, domain, title, description), which is meaningful for a metadata-introspection tool and compensates for the absent output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences: the purpose and the pre-call placement come first, the return contents second. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 must carry the return-value burden, and it does by listing the fields produced. Combined with the annotations and 100% schema coverage, an agent has everything needed to invoke it correctly.

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 100%, so operationName, userIntent, and originalQuery are all documented in the schema itself. The description only restates that a specific operation name is required, adding no syntax or format detail beyond the structured field — the baseline 3 applies.

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?

States a specific verb (Inspect/Describe) and resource (one Algolia operation), and explicitly ties the operation to algolia_discover_tools, distinguishing it from the discover and call siblings. The second sentence names exactly what metadata is returned (input schema, read/write effect, domain, title, description).

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?

"before calling it" gives clear sequencing guidance: discover → describe → call. It doesn't explicitly exclude cases or name algolia_call_read_tool as the natural follow-up, but the workflow position is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

algolia_discover_toolsDiscover Algolia ToolsA

Read-only

Inspect

Find operations that work with this user's own Algolia applications, data and configuration. Use it whenever a question is about their account, to find the operation that fetches what they asked for. Search with a short intent phrase such as 'top searches', 'index settings' or 'similar products'; omit the query to browse. Returns operation names, descriptions, domains, and read/write effects.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Results per page.
`query`	No	Concise description of the desired capability in user language. Exact Algolia operation names are not required. Omit to browse all accessible operations.
`offset`	No	Pagination offset.
`userIntent`	No	How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.
`originalQuery`	No	The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a safe, non-destructive, non-open-world read. The description adds genuinely new context: that a short intent phrase works, that omitting the query browses everything, and that results carry operation names, descriptions, domains, and read/write effects. It does not mention pagination behavior, though limit/offset are self-explanatory.

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?

Three tight sentences, front-loaded with the purpose and scope, followed by usage and then the return contents. Every sentence carries distinct information with no repetition of the schema.

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, and the description compensates by summarizing what the results contain. Combined with the usage guidance and param examples, an agent has what it needs to call this correctly; the only minor omission is pagination/result-count behavior across pages.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by giving concrete example query values ('top searches', 'index settings', 'similar products') and confirming exact operation names are not required. That materially clarifies how to populate the query parameter.

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?

States a specific verb (find/discover) and resource (operations over the user's own Algolia account, data, and configuration), and clarifies the scope as the user's own account rather than general docs. That framing distinguishes it from algolia_call_read_tool, algolia_describe_tool, and algolia_knowledge_search without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it whenever a question is about the user's account and that it exists to locate 'the operation that fetches what they asked for', which is strong when-to-use guidance. It stops short of naming the sibling tools it should be preferred over, so the routing guidance is clear but not fully comparative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

algolia_knowledge_searchSearch Algolia KnowledgeA

Read-only

Inspect

Answer a general question about Algolia from Algolia's official documentation and support articles. Returns passages, each with its source URL. Use this for questions about how Algolia works, what a parameter or concept means, plan and billing questions, error messages, and troubleshooting. This content is keyword-matched, not semantic: pass distilled search terms, not the user's sentence, and pass several variants so a vocabulary mismatch in one does not lose the answer.

ParametersJSON Schema

Name	Required	Description
`question`	Yes	The user's question verbatim, one sentence, no greetings or backstory. Searched as written: these pages are titled as questions, so the user's own wording often matches a title that keywords miss.
`maxResults`	No	Maximum passages to return (default 3, max 5).
`userIntent`	No	How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.
`searchTerms`	Yes	The same question translated for a keyword engine: up to 5 short phrases built from words the page itself would use — the feature or parameter name, the symptom, the likely title. The index is lexical, not semantic, so a word the page never uses cannot match. Results are ranked by agreement across phrases, so vary them rather than repeating. e.g. ["virtual replica usage", "replica record count", "replica billing"]
`originalQuery`	No	The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (read-only, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: retrieval is lexical keyword matching, not semantic, results are ranked by agreement across phrases, and each returned passage carries its source URL. That is exactly the mechanism an agent must understand to call this correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then return shape, then use-case enumeration, then query-construction guidance. Dense and waste-free, though the middle use-case list is somewhat enumerative rather than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 supplies the return format (passages plus source URLs) itself, covers when to use it, and explains input construction. Combined with fully documented parameters and safety annotations, nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining why distilled variants of searchTerms are needed ('a vocabulary mismatch in one does not lose the answer') and why the question is passed verbatim (pages are titled as questions). It adds rationale and usage nuance beyond the schema text.

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?

States a specific verb and resource: answer general Algolia questions from official documentation and support articles. The resource scope (docs/support content) clearly separates it from the sibling tools that manipulate the tool catalog, though no sibling is named explicitly.

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?

Enumerates concrete when-to-use contexts: how Algolia works, parameter/concept definitions, plan and billing questions, error messages, troubleshooting. It also specifies when keyword search beats semantic search, but states no explicit exclusion or named alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesOct 5, 2026

Changedalgolia_call_read_tool2 fields changed

addedInput schema / properties / originalQuery

Added value: +{
+  "description": "The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.",
+  "type": "string"
+}

addedInput schema / properties / userIntent

Added value: +{
+  "description": "How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.",
+  "type": "string"
+}

Changedalgolia_describe_tool2 fields changed

addedInput schema / properties / originalQuery

Added value: +{
+  "description": "The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.",
+  "type": "string"
+}

addedInput schema / properties / userIntent

Added value: +{
+  "description": "How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.",
+  "type": "string"
+}

Changedalgolia_discover_tools2 fields changed

addedInput schema / properties / originalQuery

Added value: +{
+  "description": "The original, unmodified user prompt that was sent to the LLM. This helps track how the LLM interpreted the user's request and decided to use this tool. Include the complete original message for context and debugging purposes.",
+  "type": "string"
+}

addedInput schema / properties / userIntent

Added value: +{
+  "description": "How the LLM interpreted the user's intention and decided to use available tools to achieve the result. Describe the user's goal and the reasoning behind choosing this tool (e.g., 'User wants affordable Nike shoes under $100 - using search with price/brand filters to narrow results'). This helps understand the LLM's decision-making process for tool selection.",
+  "type": "string"
+}

Addedalgolia_knowledge_search

Related MCP Connectors

ComposioOAuth
io.github.ComposioHQ
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
Agent Orchestration App Automation
21
Store MCPOAuth
com.store-mcp
Connect AI to store orders, products and inventory with scoped access and human approvals.
E-commerce & Retail ERP Systems
1
Proofable MCP AOAuth
io.github.proofable
Context and control for any AI. Agent identity, scoped access, and proof across tools.
Security Agent Orchestration Autonomous Agents
1
MiniURL A
io.github.addychang
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
Marketing Developer Tools
232

Related MCP Servers

aria-service-desk-assistant
RAG Systems Search Content Management Systems
emran-Automation-Techlead
A
license
Not graded
quality
C
maintenance
Enables AI assistants to search internal knowledge bases, create Confluence articles, file Jira tickets, and look up Okta users, with guardrails and streaming support.
Updated a month ago (2026-09-08 19:30 UTC)
MIT
ToolBridge
Autonomous Agents Security
Sehrabdar
A
license
Not graded
quality
B
maintenance
Enables autonomous AI agents to securely access and execute external tools, such as GitHub REST API operations, with per-user authentication, authorization, audit logging, and observability.
Updated 15 days ago (2026-09-30 06:21 UTC)
MIT
MCP Gateway
Agent Orchestration API Testing
jowpereira
-
license
Not graded
quality
Not graded
maintenance
A secure bridge that allows Large Language Models (LLMs) to interact with corporate APIs and services in a controlled and contextualized manner.
Updated a year ago (2025-05-10 16:34 UTC)
-
mcp-fetch-worker
Security Cloud Platforms
jkpe
F
license
Not graded
quality
C
maintenance
Enables AI bots and agents to call self-hosted APIs behind Cloudflare Access through a single HTTP fetch tool, using human-approved OAuth tokens instead of long-lived credentials.
Updated 2 months ago (2026-08-24 15:45 UTC)
2
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?