Infino MCP server

Official

by infino-ai

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.10.0
Disambiguation5/5
Each search tool serves a distinctly different mode (unranked token match, ranked BM25, semantic vector, hybrid, exact equality, count), and the descriptions explicitly cross-reference when to use each. Metadata tools (list/describe tables) and SQL are clearly separate.
Naming Consistency5/5
All tools follow a consistent infino_ prefix with snake_case, and the second component is either a verb (list, describe, count, search) or a clear action noun (token_match, exact_match). No mixed styles.
Tool Count5/5
9 tools is well-scoped for a search/query server, covering metadata discovery, multiple search paradigms, and a flexible SQL query interface without unnecessary bloat.
Completeness5/5
The tool surface comprehensively covers the read-only search/query domain: table discovery, schema inspection, keyword/semantic/hybrid/exact search, counting, and arbitrary SQL aggregation. No critical missing operations for its intended purpose.
Average 4.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does state that the tool returns column names and types, implying a read-only metadata operation. However, it does not explicitly state that it is non-mutating, nor does it disclose error behavior, auth requirements, or other behavioral details that could be relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence, front-loaded with the action and outcome, then immediately gives practical usage rationale. Every clause earns its place without redundancy or filler.
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?
For a simple single-parameter metadata tool with no output schema, the description is sufficiently complete: it states the return value (column names and types) and the recommended usage context (before searching). The sibling context makes it clear this is a preliminary step, so no further behavior needs explanation.
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?
The input schema has only one parameter and 100% schema description coverage, so the schema already explains that 'table' should come from infino_list_tables. The description adds usage context but does not meaningfully extend parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return a table's column names and types') and the resource (a table), which is specific and distinct from the sibling search, count, and SQL tools. It also explains the purpose of the tool ('call before searching'), reinforcing its role as an introspection utility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool before searching to identify target columns and understand result fields, giving clear contextual guidance. It does not enumerate when not to use it or mention alternatives, but there is no direct sibling that provides the same schema-description function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does disclose key behavior: it is a fast tally, performs no row fetching, and does no ranking. It does not mention edge cases like zero matches or exact count guarantees, but the stated behavior is clear and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the key purpose, and contains no redundant or filler language. Every sentence adds value: what it does, when it is cheaper, and which sibling to use instead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count tool with no output schema and no annotations, the description is largely complete: it explains the count-only behavior, the use case, the cost advantage, and the alternatives. It does not explicitly state the return type, but 'HOW MANY rows' and 'fast tally' make the integer count outcome clear enough.
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 all four parameters (table, query, mode, column) are already documented in the schema. The description adds minimal parameter-level context beyond clarifying the count-only purpose, which matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts keyword matches rather than returning rows, with a specific verb ('count') and resource ('rows matching a keyword query'). It explicitly distinguishes itself from sibling search tools by emphasizing the count-only result and naming alternatives.
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?
The description gives explicit when-to-use guidance ('Use when you only need HOW MANY rows match'), cost guidance ('Cheaper than infino_keyword_search'), and direct alternatives ('For the matching rows use infino_keyword_search or infino_token_match'). This fully covers selection between the tool and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the filter is 'unranked' and operates on an 'indexed column', which is useful behavioral context beyond the schema. However, it does not mention side effects, permissions, or error behavior, but for a read-only filter this is acceptable. It adds meaningful transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action and purpose, then distinguishing guidance. Every sentence earns its place with no filler. It is appropriately brief and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four parameters are fully described in the schema and the description names alternatives, the tool is well-covered. It does not mention the exact return format (e.g., the 'matched' field) but the schema's limit description hints at it. Overall, it is complete enough for an agent to invoke 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 the baseline is 3. The description adds minimal value beyond the schema by suggesting typical value types (tag, status, or id string), but the schema already explains each parameter clearly. The limit parameter's behavior is fully described in the schema. No extra semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches rows where a column exactly equals a value, with concrete examples (tag, status, id). It explicitly distinguishes from sibling tools by naming infino_keyword_search and infino_sql, making the purpose unambiguous and contextually differentiated.
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?
The description gives direct guidance on when to use this tool vs alternatives: 'For ranked text relevance use infino_keyword_search; for multi-column analytical filtering use infino_sql.' This is explicit and sufficient for an agent to select the correct tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the query is embedded with a local model, requires no API key, and that ranking prioritizes rows matching both literal terms and meaning. It does not mention output structure or edge cases, but it gives substantial transparency for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler. Every sentence contributes unique value: usage context, mechanism, operational detail (local embedding), and tool positioning among siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema), the description covers the use case, ranking behavior, and relationship to sibling tools. The output format is partly inferable from the schema's `columns` parameter, but the description itself does not explicitly state what a result contains beyond ranking logic, leaving a small gap.
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?
The input schema already describes all 6 parameters with 100% coverage, so the baseline is 3. The description adds conceptual context by explaining that BM25 operates over a text column and vector similarity over an embedding column, which helps map to `column` and `vectorColumn`, but it does not add per-parameter syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it fuses BM25 keyword matching with vector similarity in a single ranking pass. It also explicitly contrasts it with infino_keyword_search and infino_semantic_search, making its unique scope immediately obvious.
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?
The description opens with an explicit usage condition: 'Use when a query carries both specific terms and an intent.' It further positions the tool between keyword-only and semantic-only siblings, giving clear guidance on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and covers important behavioral aspects: returns a set (unranked), matches on indexed tokens and their stems, and notes that matches beyond limit are counted but not returned. It lacks info on ordering and whether partial column matches are included, but those are partly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and concise. Every sentence adds value, with no excessive detail. It references sibling names for alternatives without over-explaining.
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?
Given no annotations or output schema, and standard parameter schema, the description is complete for a straightforward keyword filter. It explains return behavior, alternatives, and key matching semantics. More detail could be given on ordering or exact column inference but not essential.
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 coverage is 100%, so parameters are already documented in the input schema. The description adds no new info about parameters beyond confirming the tool's operation, but it does confirm inferred column behavior. Per rubric, baseline 3 given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning the SET of rows containing a keyword as an unranked filterable operation rich in semantics (stems). It distinguishes it from siblings key_word_search and exact_match by noting absence of ranking or exact matching.
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 guidance is given for when to use this tool (unranked keyword filter) and when to use alternatives: ranked results to infino_keyword_search, analytical filtering across columns to infino_sql. It also mentions it returns rows whose column contains the token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It mentions tokenization, stemming, relevance scoring, and the inclusion of '_id' and 'score' in results. While it doesn't explicitly state the operation is read-only, the nature of a search tool implies it, and the description gives sufficient detail about what happens during execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear flow: use case, mechanism, behavior, and alternatives. However, some redundancy exists (e.g., repeating 'matches exact tokens, not synonyms or paraphrases' twice and the phrase about literal terms). It could be tightened without losing meaning, but it remains concise and easy to scan.
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?
The description fully contextualizes the tool within its sibling set, covering when to use it, how it differs from alternatives, and what to expect in terms of output (relevance scores, columns). It also touches on default behavior (e.g., column inference), making it complete for a search tool without needing to explain the return schema, which is already in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with descriptive text (e.g., 'column' explains inference from table schema, 'columns' details return behavior). The description reinforces these but adds minimal new information beyond contextual usage (e.g., mentioning 'identifiers, error codes' as example queries). Given the high schema coverage (100%), the description adds modest value, warranting a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs BM25 full-text search and ranks results by relevance, specifically for literal terms like identifiers and error codes. It also distinguishes itself from sibling tools (semantic and hybrid search) and SQL LIKE, making its purpose unambiguous.
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?
The description explicitly advises using this tool for literal term queries and exact phrases, and directs users to alternative tools for meaning-based search (infino_semantic_search) or combined use (infino_hybrid_search). It also recommends preferring this over SQL LIKE for known literal terms, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description conveys that this is a read-only discovery operation with no side effects. It adds context about the intended call order, which is useful behavioral information. The return value (list of tables) is implied by 'List the tables,' though not explicitly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the action verb 'List' front-loaded. Every sentence provides value: the first states the function, the second explains when to use it. There is no unnecessary wording.
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?
Given the tool's low complexity (no parameters, no output schema), the description sufficiently covers its purpose and usage context. The instruction to call it first is especially valuable given the large number of search/query siblings, making the description contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the parameter space. The description adds no parameter-specific meaning, but none is needed. The baseline for 0 parameters is 4, and this is appropriately met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'tables in the connected catalog', making the tool's function immediately clear. It also distinguishes this from sibling search/query tools by framing it as a discovery step.
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?
The description explicitly states when to use the tool: 'Call this first to discover what is available to search or query.' This provides clear sequencing guidance and explains the tool's role relative to other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the local embedding model (no API key), vector-similarity ranking, per-hit scores, and the filter's pushdown pre-filter behavior. It does not explicitly state that the operation is read-only or describe error cases, but for a search tool the disclosed behavior is substantive.
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 dense, front-loaded sentences cover use case, mechanism, filter semantics, and alternatives. No filler or repetition—every sentence earns its place.
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?
Given 7 parameters, a nested filter object, and no output schema, the description is remarkably complete: it explains purpose, matching behavior, scoring, filter semantics, and sibling-tool boundaries. The remaining parameter details are fully covered by the 100% schema description.
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 adds meaningful semantics for 'filter' (pushdown pre-filter, example with 'billing') and clarifies that 'query' is embedded for vector matching. This goes beyond the schema while not over-explaining what is already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search by meaning', 'retrieves paraphrases and synonyms') and clearly identifies the resource (a table's embedding column). It distinguishes semantic search from keyword and hybrid search by explaining the conceptual matching behavior, so it fully differentiates from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with explicit when-to-use guidance ('Use when searching for a concept by meaning and the exact wording is unknown') and names exact alternatives: infino_keyword_search for exact terms and infino_hybrid_search for mixed literal+intent queries. This is model-guidance gold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only and that DDL/DML is rejected. It explains how search functions behave (table-valued relations, embedding requirement for vector/hybrid) and includes an example. This gives a clear picture of the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured. It covers all necessary aspects without being redundant. While it is somewhat lengthy, the information is valuable and presented logically, with an example at the end.
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?
Given the tool's complexity (SQL with embedded search), the description is comprehensive. It explains the read-only nature, the syntax for search functions, the embedding workflow, and gives a concrete example. There is no output schema, but the description implies result rows, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the query parameter by specifying it must be a SELECT or WITH statement, and to the embed parameter by explaining it maps placeholders to text that will be embedded and substituted. It also provides an example of the embed usage, enriching the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for structural or analytical questions (counts, GROUP BY, joins, aggregates) and returns result rows. It distinguishes itself from the sibling search tools by framing it as a general SQL interface for queries that go beyond simple search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use for structural or analytical questions' and explains the search functions are callable within SQL, implying when to use SQL versus the dedicated search tools. It also notes the read-only constraint, which is a usage guideline. However, it could be more explicit about when not to use SQL (e.g., for simple keyword retrieval, prefer the search tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![infino-mcp MCP server](https://glama.ai/mcp/servers/infino-ai/infino-mcp/badges/score.svg)](https://glama.ai/mcp/servers/infino-ai/infino-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/infino-ai/infino-mcp'

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