ai-toolkit
Server Details
AI tools for agents: chat, summarize, classify, entity extraction, embeddings, transcription. x402
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- agishub/agishub-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 6 of 6 tools scored.
Each tool targets a distinct AI task (chat, classify, embed, entities, summarize, transcribe) with no functional overlap, making selection unambiguous.
All tool names use a consistent single-word verb format (with underscores only where needed, as in 'extract_entities'), following a clean, predictable pattern.
Six tools cover a broad range of common AI text and audio processing tasks without being excessive or sparse, fitting the server's purpose well.
Core NLP operations are covered, but there are minor gaps like translation or image analysis; however, the set is reasonable for a general-purpose AI toolkit.
Available Tools
6 toolschatAInspect
Ask a general-purpose LLM a question or give it an instruction, with an optional system prompt. Runs on Cloudflare Workers AI (Llama 3.3) — no external API key.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The user's message or question for the assistant. | |
| system | No | Optional system instruction to steer the assistant's behaviour/persona. | |
| max_tokens | No | Maximum tokens to generate (default 512). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions the model backend and that no external API key is needed. However, it does not disclose rate limits, latency, statelessness, or error behavior. Adequate but not comprehensive.
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, no wasted words, front-loaded with key information. Efficient and clear.
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 3-param tool with no output schema or annotations, the description is mostly complete. It covers purpose, model, and environment. Lacks mention of response format and usage guidelines, but given low complexity, it is near-complete.
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% (all parameters described). Tool description adds the context of 'general-purpose' and optional system prompt, but does not provide additional semantics beyond the schema. 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?
Description clearly states the tool is for asking a general-purpose LLM a question or instruction, specifies the model (Llama 3.3) and environment (Cloudflare Workers AI, no API key). This distinguishes it from siblings like classify, embed, summarize, which are specialized.
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 explicit guidance on when to use this vs siblings. The description says 'general-purpose' implying broad use, but doesn't contrast with specialized tools. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
classifyAInspect
Classify a text into exactly one of the candidate labels you provide (e.g. sentiment, topic, intent). Runs on Cloudflare Workers AI.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to classify. | |
| labels | Yes | Candidate labels to choose from, e.g. ['positive','negative','neutral']. |
Tool Definition Quality
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 running on Cloudflare Workers AI but does not disclose limits, auth needs, or other behavioral traits beyond the single-label constraint.
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 no wasted words. The first sentence covers the primary purpose and the second adds platform context. Perfectly sized for the tool's simplicity.
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 with two parameters and no output schema. The description covers core functionality but omits output format specifics. Given the simplicity, it is mostly complete.
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 3. The description adds slight reinforcement ('exactly one candidate') but does not provide new semantic information beyond what the schema already states.
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?
Clearly states the verb 'classify' and resource 'text', and specifies the output is exactly one label from provided candidates. Distinguishes from siblings like chat, embed, etc.
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 examples (sentiment, topic, intent) and clarifies single-label selection, but does not explicitly state when not to use or mention alternatives. Adequate for a simple classification tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
embedAInspect
Turn text into a numeric embedding vector for semantic search, RAG and similarity. Multilingual (BGE-M3). Runs on Cloudflare Workers AI.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to embed into a numeric vector for semantic search / RAG. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions multilingual and platform (Cloudflare Workers AI) but lacks details on token limits, output format (e.g., vector dimensions), or side effects. Behavior is partially described but incomplete.
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?
Three concise sentences, front-loaded with the core function, no wasted words. Every sentence 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?
For a simple one-param tool with no output schema, description covers purpose, model, and platform. Missing explicit mention of output as a numeric array, but otherwise 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?
Schema description coverage is 100%, with the 'text' param already described as 'Text to embed...'. Tool description adds multilingual context but no additional parameter constraints or format details. Baseline 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?
Description clearly states the tool converts text to numeric embedding vectors for semantic search, RAG, and similarity. It specifies multilingual capability and the model (BGE-M3), distinguishing it from siblings that perform different functions.
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?
Usage is implied for semantic search, RAG, and similarity, but no explicit guidance on when to use vs alternatives or when not to use. Sibling tools are distinct, so context is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_entitiesAInspect
Extract named entities from text — people, organizations, locations, dates and miscellaneous — returned as structured JSON. Runs on Cloudflare Workers AI.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to extract named entities from. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool runs on Cloudflare Workers AI (implying server-side execution) but does not disclose whether it's read-only, has rate limits, or whether errors occur on invalid input. Basic behavioral context is missing.
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 no filler. Front-loaded with the action and resource, followed by output format and deployment detail. Every 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?
Given one parameter, no output schema, and no annotations, the description is complete enough for a straightforward extraction tool. It explains what it extracts, the output format, and where it runs. Could mention return structure more explicitly but 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?
Schema coverage is 100% for the single 'text' parameter. The description adds value by stating the output is structured JSON and listing entity types (people, organizations, etc.), providing meaning beyond the schema's minimal parameter description.
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 uses a specific verb ('Extract') and resource ('named entities from text'), lists example entity types, and clearly distinguishes from sibling tools like 'chat' or 'summarize' which perform different tasks.
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 explicit guidance on when to use this tool versus alternatives. While the sibling tools have different purposes (e.g., classify, transcribe), the description doesn't mention when extraction is appropriate or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarizeAInspect
Summarize a block of text into a short abstract, with an optional target length. Runs on Cloudflare Workers AI — no external API key.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to summarize. | |
| max_words | No | Approximate maximum length of the summary, in words (default ~80). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the execution environment and that no external key is needed, but does not mention limitations like maximum input length or supported languages.
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 the core purpose, 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 2 parameters and no output schema, the description provides essential information: what it does, the optional parameter, and the low-friction deployment. Lacks input length details but 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?
Schema descriptions already cover both parameters. The description adds 'optional target length' and clarifies the default (~80 words), but this is marginal additional value since schema coverage is 100%.
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 summarizes text into a short abstract with an optional target length. It distinguishes from sibling tools (chat, classify, etc.) by focusing on summarization.
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 it runs on Cloudflare Workers AI with no external API key, implying ease of use, but does not explicitly state when to use this tool versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transcribeAInspect
Transcribe an audio file (given by public URL) to text using Whisper. Handles mp3, wav, m4a, ogg and more. Runs on Cloudflare Workers AI.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_url | Yes | Public URL of an audio file (mp3, wav, m4a, ogg, ...) to transcribe to text. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the model (Whisper), runtime (Cloudflare Workers AI), and supported formats, but omits details like file size limits, language support, or response format.
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 with no wasted words; every sentence provides essential information (function, input, model, formats, runtime).
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 one parameter and no output schema, the description covers input, output, model, formats, and runtime. It could mention if transcription is synchronous or include return format, but is reasonably complete.
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% and the schema description already explains the audio_url parameter. The tool description adds context about Whisper and Cloudflare but does not enhance parameter meaning significantly 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 transcribes audio files to text using Whisper, specifying the input (public URL) and supported formats (mp3, wav, etc.). It distinguishes from siblings like chat or classify which perform different tasks.
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 clear context for use (audio transcription) without explicit when-not-to-use or alternatives, but the purpose is sufficiently specific and different from sibling tools to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!