Gorilla MCP

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a distinct part of the lead generation workflow: billing, idea refinement, lead searching, outreach, and run management. No two tools have overlapping purposes; descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent 'category.action' naming pattern (e.g., account.billing, leads.find, outreach.draft). The pattern is predictable and uniformly applied across the entire set.
Tool Count5/5
With 9 tools, the set covers the end-to-end process from billing check to outreach planning without being excessive. Each tool serves a clear, necessary function within the server's domain.
Completeness4/5
The toolset covers the main workflow comprehensively: billing, idea refinement, multiple search modes, outreach drafting and planning, and run history. Minor gaps include lack of run deletion or account update tools, but these are not essential for core functionality.
Average 4.6/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
- 1 commit in the last 12 weeks
- Last stable release on April 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is idempotent, but annotations set idempotentHint=false, creating a direct contradiction. While the description adds useful behavioral details (stateless, no DB writes, no credit consumption), the contradiction undermines transparency and could mislead the agent.
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 dense but well-organized: purpose first, then behavioral notes, usage instructions, and return fields. Every sentence adds value; there is no redundancy or fluff. It is concise for the complexity involved.
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 (multi-turn conversational refinement) and no output schema, the description fully explains the return structure (status, refined_idea, readiness_score, etc.) and the stopping condition (score ~75 or max_turns). It is self-contained and 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?
Schema coverage is 100%, so baseline is 3. The description adds context beyond schema descriptions, such as that 'idea' stays the same across turns, 'current_refined_idea' should be omitted on first turn, and 'history' is appended each turn. This enriches the meaning for the agent.
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 refines a SaaS idea conversationally, with a specific verb ('refine') and resource ('SaaS idea'). It distinguishes itself from siblings by warning not to call after leads.find, establishing it as a pre-search 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 provides explicit step-by-step usage: first turn with just idea, then subsequent turns with history. It also states when not to use ('Do NOT call idea.refine after leads.find has already run') and implies alternatives (leads.find, idea.expand).
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?
The description discloses that it bypasses AI scoring, consumes one credit per call, and conditionally persists results via run_id. Annotations only provide basic hints (readOnlyHint=false), so the description carries the transparency burden well, though it could mention that it is effectively non-caching or rate-limited.
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: purpose first, then behavior, usage, and return info. Each sentence adds value, but it is slightly verbose for a search tool (could shorten the alternative guidance to one sentence).
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?
With no output schema, the description explains the return format (leads array with no lead_score, plus count). It also covers credit consumption and integration with runs. For a tool with 3 parameters, it is nearly complete, though it omits any error conditions or pagination behavior.
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%, and the description adds meaning: it explains that queries are passed through unaltered, that source accepts aliases ('twitter' for 'x'), and that run_id causes persistence. This goes beyond the schema's basic descriptions.
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 states a specific verb and resource ('Run an ad-hoc search against ONE social platform') and lists the exact platforms, clearly distinguishing from the sibling leads.find via behavioral differences (bypassing theme-expansion and AI scoring).
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 says when to use this tool ('when leads.find under-fetched on a specific platform, or to test custom query phrasings') and when not to ('Do NOT use this as a substitute for leads.find when you want full pipeline behaviour'). Also provides an alternative (leads.find).
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?
Annotations already declare readOnlyHint=true. Description adds key behaviors: 'Consumes one credit,' 'Stateless; nothing persists,' and that it uses the same endpoint as leads.find. This goes beyond the annotations to explain side effects and internal mechanics, but does not cover all potential edge cases.
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 clear sections (Behavior, Usage, Returns). It is somewhat lengthy but every sentence adds value, including the warning about double-billing. However, it could be slightly more concise by removing minor 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?
For a simple tool with one parameter and no output schema, the description covers everything: purpose, behavior, usage, return structure, and important caveats (credit consumption, statelessness, double-billing risk). No gaps remain for effective agent usage.
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% with a clear description for 'idea'. The description adds context by framing the parameter as a 'product idea' and specifying the output categories (core keywords, etc.), which helps the agent understand the transformation.
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?
'Generate the keyword scaffolding... for a product idea, without running searches' clearly states the action and output. It distinguishes from sibling leads.find by noting that leads.find runs theme expansion itself, thus avoiding conflating the two.
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?
Explicitly states when to use: 'when the user wants to see the search scaffolding before committing to a full run, or when planning manual outreach copy.' It also gives an explicit when-not: 'Do NOT use this as a precursor to leads.find... calling both is double-billing.' This provides clear alternatives.
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?
Annotations already indicate idempotent and read-only; description adds client-side synthesis, fetching via runs.get, bucketing leads at >=0.7, per-channel cadence heuristics (Reddit/X 3-4/day, others 2/day), and free. No contradictions.
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?
Well-structured with purpose first, then behavior, usage, returns. Somewhat lengthy but every sentence adds value. Could be slightly more concise but clear.
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 single param with full schema and no output schema, description fully explains return format (multi-line text with breakdown, cadence, action register, deprioritisation rule) and prerequisites (run completed, HIGH leads >=5). Complete.
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?
Only one parameter (run_id) with 100% schema coverage, description merely restates the schema (run_id returned by leads.find). Adds no new meaning beyond schema, so baseline 3.
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?
Clearly states it builds a Week-1 outreach plan from HIGH-intent leads with per-channel cadence and per-category action register. Distinguishes from siblings like leads.find (raw lead dump) and outreach.draft (drafting messages).
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?
Explicitly says to call immediately after leads.find, skip if HIGH lead count is under 5 (heuristic fails), and not to call on still-running run. Provides clear when-to-use and when-not-to-use.
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?
Discloses read-only DB query, user-scoped, no external calls, no credit consumed, idempotent. Annotations already cover readOnlyHint and idempotentHint, but the description adds context on scope and credit consumption, which is helpful but not essential.
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?
Concise and well-structured: front-loaded with main functionality, then behavior, usage guidance, and return format. Every sentence adds value with no 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?
Given no parameters and no output schema, the description fully covers the tool's purpose, behavior, usage context, and return format (fields, ordering). No gaps.
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?
No parameters in schema (100% coverage). Description doesn't need to add parameter details; baseline 4 for zero parameters.
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?
Clearly states the tool lists the user's recent lead-generation runs with specific constraints: newest first, capped at 50. Distinguishes from siblings like runs.get and leads.find by specifying the resource and scope.
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?
Provides explicit when-to-use scenarios (revisit previous hunt, get run_id, confirm completion) and a when-not-to-use (enumerate other users' runs). Names alternative tools like runs.get and outreach.plan.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it's free, no credit consumed, hits a specific edge function, and values only change on Stripe webhooks, providing rich behavioral context beyond annotations.
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?
Description is somewhat long but well-organized with clear sections (Behavior, Usage, Returns). Every sentence adds value, though minor redundancy could be trimmed.
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?
Despite lacking an output schema, the description enumerates return fields and their possible values. Combined with usage context, it fully equips the agent to understand and invoke the tool correctly.
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?
No parameters exist in the schema, so description doesn't need to add parameter info. Baseline for 0 params is 4, and the description provides no parameter details, which is appropriate.
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 it checks billing status including specific fields like plan, runs, credits. It distinguishes itself from sibling tools (e.g., leads.find) by being about billing rather than lead search.
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?
Explicitly advises to call before leads.find or leads.search to confirm runs availability, and after billing-error responses. Also warns against polling on a schedule, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pipeline dispatch, blocking (60-120s), credit consumption, and idempotency via run_id, adding context beyond annotations.
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?
Somewhat lengthy but every sentence adds value; front-loaded with purpose and behavior.
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 output schema, the description thoroughly details return structure and behavior (blocking, credit, run_id), making it complete for the agent.
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?
Adds context to the 'idea' parameter (e.g., 'the problem the user's SaaS solves', suggests refining short ideas), which improves upon the schema's basic description.
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 finds ranked social posts across multiple platforms matching the user's SaaS problem, distinguishing it from siblings like leads.search and idea.refine.
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?
Provides explicit guidance: when to call, not to call twice, pair with idea.refine, and hand run_id to outreach tools. Also warns against duplicate spending.
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?
Annotations already declare readOnly, non-destructive, idempotent. Description adds valuable behavioral context: read-only DB query, no external calls, no credit consumed, 'safe to poll', and partial results if status is 'running'.
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?
All sentences are relevant and front-loaded. Slightly verbose with repeated mentions of 'outreach.plan or outreach.draft' and 'leads.find', but still efficient.
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?
No output schema, but description fully explains return structure: run_id, status, idea text, results array with field details, and metadata. Covers all necessary information for the agent.
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% with run_id description already clear. Description adds meaning by specifying the source of run_id (from leads.find) and giving example format 'run_abc123', plus contextualizing its usage.
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?
Clear verb 'Fetch the full result' and resource 'previously-started run by its run_id'. Distinguishes from siblings by mentioning runs.list for finding run_ids and leads.find for starting runs.
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 when-to-use scenarios: re-analyse earlier run without spending credit, hand leads to outreach.draft/plan, poll long-running job. Also states what NOT to do: 'Do NOT call this without an existing run_id; use runs.list first.'
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?
Discloses key behaviors beyond annotations: persists nothing, consumes one credit per draft, and each call is independent. No contradiction with readOnlyHint=true or other annotations.
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?
Well-structured and concise: starts with purpose, then behavior, usage, and exclusions. Every sentence is necessary and informative.
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?
Thorough for a complex tool with 9 parameters and no output schema. Covers behavior, side effects, usage patterns, and negative examples. Return format is adequately described.
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% with good descriptions. The description adds extra context for outreach_action options and clarifies optional parameters like post_handle. However, schema already handles basic semantics.
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 it generates platform-tuned outreach messages for a specific lead. It distinguishes from sibling tools like outreach.plan and leads.find by specifying the purpose and context.
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?
Provides explicit usage guidance: call once per lead from leads.find, detailed explanations of outreach_action variants, and negative instructions to avoid COMPETITOR-flagged leads and generic copy.
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:

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

Score Badge

Copy to your README.md:

[![gorilla-mcp MCP server](https://glama.ai/mcp/servers/opusforge/gorilla-mcp/badges/score.svg)](https://glama.ai/mcp/servers/opusforge/gorilla-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/opusforge/gorilla-mcp'

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