mcp-deal-flow-signal
Server Quality Checklist
Latest release: v1.0.8
- Disambiguation5/5
Each tool has a distinct purpose: overview, methodology, trending, sector search, and individual startup details. The descriptions include 'DO NOT USE FOR' sections that further clarify boundaries, making selection unambiguous.
Naming Consistency4/5Four tools follow the 'get_' pattern, while one uses 'search_'. The naming is otherwise consistent (snake_case, verb_noun), and the deviation is justified by the different action, but it still breaks the pattern slightly.
Tool Count5/5With 5 tools, the server covers the main use cases without bloat. Each tool earns its place, providing a well-scoped surface for deal flow signal exploration.
Completeness5/5The set covers discovering startups (trending and by sector), getting detailed profiles, understanding methodology, and checking dataset freshness. No obvious gaps for the stated purpose.
Average 4.8/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This server has been verified by its author.
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
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds details: 24h cache, no client auth needed, error conditions, database bias, and returns structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded with core function. Slightly verbose but all information is relevant and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Includes limitations, return values, typical workflow, and error handling. Output schema is described comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema coverage; description includes typical workflow but adds little beyond schema details like format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a Scout Score from public starring history, cross-referencing against validated unicorns. It distinguishes from sibling tools like get_trending_startups and get_startup_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'WHEN TO USE' and 'DO NOT USE FOR' sections, listing specific use cases and alternative tools for different needs.
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?
Beyond annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: per-request pricing, credit consumption only on success, authentication via env variable, error responses (401, 402, 400), and the inclusion of balance and charged in returns. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section headings (PRICING, AUTHENTICATION, WHEN TO USE, etc.) and front-loaded with purpose and pricing. Every sentence provides valuable information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paid, authentication, rich output), the description comprehensively covers pricing, auth, usage guidelines, parameter details, return fields, and error handling. The existence of an output schema reduces the burden, but the description still adds context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'name' parameter fully documented. The description adds minimal extra value (case-insensitivity hint, reference to free lookup). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a deeply enriched signal profile for a single tracked startup, explicitly listing components like scored breakdown, in-sector rank, comparables, history, and thesis. It distinguishes itself from the free sibling get_startup_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit WHEN TO USE and DO NOT USE sections, including specific scenarios (memo preparation, programmatic ranking) and alternatives for discovery, bulk scoring, and methodology. This offers excellent guidance for selecting this tool over siblings.
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, idempotentHint, and destructiveHint false. The description adds extra behavioral details: 'Read-only, idempotent, no side effects', notes it is effectively static and safe to cache, explains error handling ('returns isError: true') and malformed response handling. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section headers (WHEN TO USE, DO NOT USE, BEHAVIOR, etc.) and front-loaded with purpose. While it is thorough, it remains efficient and each sentence adds value. Could slightly reduce length but overall good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, a readable output schema, and moderate complexity, the description covers all necessary aspects: usage context, behavior, return structure, typical workflow, and limitations. It provides complete guidance for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, 100% schema coverage). The description does not need to add parameter info. It goes beyond by explaining the return structure ({ methodology: string, url: string }) and provides context about the return values. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Return the full methodology behind VC Deal Flow Signal' which clearly specifies the verb and resource. It lists exactly what the methodology covers (data sources, metrics, classification, etc.) and distinguishes from sibling tools like get_startup_signal, get_trending_startups, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description has explicit 'WHEN TO USE' and 'DO NOT USE FOR' sections with multiple bullet points, naming specific alternative tools for each forbidden case. This provides clear context and exclusions.
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 read-only, idempotent, deterministic nature; no-auth requirement; case-insensitive and normalization-tolerant matching; no-match behavior (found:false, not error); open-world limitation (only ~400 companies). Annotations already provide readOnlyHint, idempotentHint, openWorldHint, but description adds crucial context (7-day refresh cycle, no historical series, expected non-error for unmatched names). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (WHEN TO USE, DO NOT USE, BEHAVIOR, PARAMETERS, RETURNS, TYPICAL WORKFLOW, LIMITATIONS). Information is front-loaded with return fields. Slightly verbose but each sentence contributes. Could condense some behavioral details but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a single-parameter tool with output schema described in RETURNS. Includes typical workflow linking to sibling tools, limitations (no historical data, no relationship info), and explicitly explains error handling (no-match vs. upstream failure). Output schema is described inline, so no missing pieces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter 'name' with description and examples. Description adds meaning: explains case-insensitivity, normalization (punctuation/whitespace stripping), and that it accepts either display name or GitHub org slug. Length constraints (1–100) are mentioned in description but not in schema. Overall adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a full engineering-acceleration profile for a single tracked startup, listing specific fields. Distinguishes from sibling tools by focusing on individual startup deep-dive vs. discovery or methodology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE (named company queries, deal memos) and DO NOT USE sections (discovery, sector listing, method explanation), with direct references to alternative tools (get_trending_startups, search_startups_by_sector, get_methodology).
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 states the tool is read-only, idempotent, has no side effects, and requires no authentication, aligning with annotations. It also discloses telemetry logging of the tool name, and clarifies it only composes posts, not posts on behalf of the user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections but is verbose. However, given the tool's complexity, the length is justified and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers typical workflow, limitations (does not post, no threads), and explains the return structure. With an output schema present, it provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value with concrete examples for the 'summary' parameter and explains the effect of 'network' and 'mention_handle', improving semantic understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool generates a ready-to-share social-media post about a result from another VC Deal Flow Signal tool. It clearly distinguishes itself from sibling tools that retrieve signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'WHEN TO USE' section listing specific scenarios and a 'DO NOT USE FOR' section clarifying it does not post on the user's behalf or generate fake results. This provides clear context for when to invoke the tool.
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?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds deterministic behavior within 7-day window, refresh schedule, authentication/rate limit info, exact row count conditions, error handling, and universe evolution. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections. Every sentence provides useful information. Front-loaded with core purpose. No redundancy despite comprehensive coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, output format (with schema reference), typical workflow, and limitations. No gaps; all aspects needed for correct invocation are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description explicitly states 'PARAMETERS: None', which suffices. With zero parameters, baseline is 4; no additional value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns top 20 startups ranked by engineering acceleration across all sectors for the current period. Distinguishes from siblings by specifying what it does not cover 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'DO NOT USE FOR' sections with specific user intents and named sibling tools (e.g., search_startups_by_sector, get_startup_signal). Comprehensive guidance on when to invoke this tool.
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?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: deterministic within a 7-day window, no auth required, no rate limit, return count range (5-30), error handling for unknown and upstream failures, and open-world dynamic updates. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections and front-loaded purpose. Each section serves a purpose; no redundant fluff. Slightly verbose but appropriate for the complexity of the tool; scores a 4 rather than 5 due to minor redundancy (e.g., repeating 'one slug per call' in multiple places).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage, strong annotations, and implied output schema, the description covers all necessary aspects: purpose, usage, behavior, parameter semantics, error handling, limitations, and typical workflow. It leaves no gaps for an AI agent to misunderstand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and includes description and enum. The description massively adds value by providing a comprehensive fuzzy-to-slug mapping table, examples, and the constraint that exactly one slug is accepted per call. This compensates beyond the schema's own documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the function: 'Return every tracked startup within one of 20 supported sectors, ranked by engineering acceleration for the current reporting period.' The verb is specific, the resource is clear, and the scope is delineated. The 'DO NOT USE FOR' section further distinguishes it from sibling tools like get_trending_startups and get_startup_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains dedicated 'WHEN TO USE' and 'DO NOT USE FOR' sections with explicit conditions, alternative tool names, and a typical workflow example. This provides clear guidance on when to invoke this tool versus others such as get_trending_startups or get_signals_summary.
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?
Beyond annotations (readOnlyHint, idempotentHint), the description adds behavioral details: deterministic within 7-day window, no auth, lightest endpoint, failure behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, front-loaded key info, and no fluff. Every sentence adds value for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an output schema, the description still provides full coverage: return fields, usage timing, limitations, and typical workflow. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description correctly omits parameter details and instead explains the return structure and limitations, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources ('Return a high-level snapshot of the VC Deal Flow Signal dataset...') and lists concrete data points. It distinguishes from siblings by naming alternative tools for different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' and 'DO NOT USE FOR' sections provide explicit context and exclusions, directly referencing sibling tools with clear rationale.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/kindrat86/mcp-deal-flow-signal'
If you have feedback or need assistance with the MCP directory API, please join our Discord server