@apexfdn/copilot-mcp

Official

by Apex-Foundation

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a unique aspect of Web3 project support: security audit, fundraising, hackathons, legal jurisdiction, portfolio matching, due diligence, social media audit, and verification. There is no overlap in functionality.
Naming Consistency5/5
All tool names follow the pattern 'apex_<noun_or_noun_phrase>' using snake_case, such as apex_code_review, apex_fund_match, apex_hackathons, etc. The naming is uniform and predictable.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose—covering key areas like audits, fundraising, legal, and scoring without being too sparse or overwhelming.
Completeness4/5
The server covers core Web3 founder needs: security, fundraising, events, legal, benchmarking, scoring, and social presence. Minor gaps exist (e.g., no direct team vetting beyond score), but overall it is comprehensive.
Average 4.6/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- Last stable release on May 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds details about the output structure (ranked verdict, recommendations, trade-offs, alternates) and coverage (28 domiciles), providing useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a clear structure: purpose, coverage, output, usage guidance. It is concise with no wasted words, and the key purpose is front-loaded.
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 10 parameters, annotations, and output schema, the description sufficiently explains what the tool does and what to expect. It covers the main outputs and use cases. Minor omission: it does not explain the ranking algorithm, but that is not essential for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter clearly. The description adds the list of domiciles and notes that the optional 'description' parameter does not affect ranking. This provides additional context, but per the baseline rule for high schema coverage, a score of 3 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 explicitly states the tool's purpose: recommend the best legal jurisdiction for a Web3 project. It lists the 28 domiciles covered and describes the output format. This clearly distinguishes it from siblings like apex_code_review or apex_portfolio_match.
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 provides explicit usage guidance: 'Use this when the founder is incorporating, restructuring, or evaluating a domicile their lawyer recommended.' While it doesn't specify when not to use it, the positive use cases are clear and adequately inform the agent.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds behavioral context by listing the detailed output components (reach, activity, engagement, authenticity, discourse) and mentioning overlap with Apex-network funds, which goes beyond the annotations. However, it does not disclose potential rate limits or authentication requirements.
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 consists of three concise sentences. The first sentence states the primary purpose, the second enumerates the output details, and the third provides usage guidance. Every sentence is informative, and there is no redundant or filler content.
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 that an output schema exists, the description is not required to detail return values. It already lists the five dimensions, summary, recommendations, raw metrics, and fund overlap, which comprehensively covers what the tool produces. This is complete for an audit tool with a rich output schema.
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%: both parameters (handle, ticker) have clear descriptions in the schema. The description restates the format for handle but does not add meaningful new semantics beyond what the schema already provides. Therefore, value added is minimal, resulting in a baseline score of 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?
The description clearly states the action 'Audit' and the resource 'X (Twitter) account of a Web3 project'. It specifies the output: a 0-100 score, breakdown across 5 dimensions, summary, recommendations, raw metrics, and fund overlap. This makes the purpose highly specific and distinct from sibling tools like apex_verify or apex_score.
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 states when to use the tool: 'when asked to evaluate a project's social presence, check for inflated metrics, or see which Apex funds have engaged'. It provides clear usage context but does not explicitly exclude other scenarios or name alternative sibling tools for comparison, which would warrant a 5.
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, idempotentHint, and non-destructive nature. The description adds that Apex partners get a priority boost with direct intros, and describes the return fields. 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?
The description is concise at about 5 sentences, front-loaded with purpose and returns, then special info and usage. It is well-structured without 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?
Despite having an output schema, the description still lists return fields (similarity scores, recent investments, tier, geography, whyMatch) and explains the priority boost. All parameters are covered with contextual hints. The description is fully complete for the tool's complexity.
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%, but the description adds value by explaining that the 'description' field is embedding-matched and that 'specific is better', and clarifies that stage, chain, sector are soft filters. 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 clearly states the tool finds Web3 funds, angels, accelerators, family offices, and CEX venture arms most likely to back a project, returning a ranked list with specific details. It distinguishes from siblings by specifying fund types and filters, and the verb 'Find' combined with the resource is specific.
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 lists three use cases (who to approach, lead investors, CEX venture arms as listing path) and mentions filters. It lacks explicit when-not-to-use but provides clear context for when to invoke.
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 indicate readOnly, idempotent, non-destructive. Description adds return details (scores, whyMatch, shortLesson) and hints at matching behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each essential. Front-loaded with action, then returns, then use cases. No wasted words.
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?
Covers purpose, use cases, and param hints. Output schema exists, so return details are handled. With 6 params and 1 required, description is sufficiently 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 description adds limited param detail. However, it provides extra context for the `description` parameter (concrete/specific yields better matches), improving semantics beyond 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 finds Apex portfolio projects similar to a founder's idea, returns a ranked list with similarity scores, rationale, and lesson. It distinguishes from siblings like apex_fund_match by focusing on portfolio matching.
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?
Provides explicit use cases: surface closest projects, identify reference customers, check thesis overlap. Lacks 'when not to use' or alternatives, but context is clear.
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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context: embedding matching, indexed sources (ETHGlobal, Devfolio, Devpost Web3-filtered, Colosseum, major annual events), and the behavior of searchPriorBuilds returning past projects. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action in the first sentence and providing usage and source details in the second. Every sentence earns its place with no wasted words.
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 (7 parameters, 1 required, 100% schema coverage, output schema exists), the description covers purpose, usage, parameters, and data sources comprehensively. It does not need to explain return values because an output schema is present.
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 description coverage is 100%, so baseline is 3. The description adds meaning beyond schema: it explains that description is 'embedding-matched against indexed hackathons (and prior projects, if requested)', gives examples for chains, and clarifies that searchPriorBuilds checks if someone has built something similar before committing.
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: finding upcoming Web3 hackathons matching a project description, and optionally surfacing prior hackathon projects. It distinguishes itself from sibling tools (e.g., apex_fund_match, apex_portfolio_match) by focusing specifically on hackathons, making it easy for an agent to select correctly.
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 provides explicit usage guidance: 'when a founder asks where they could enter their project, whether anyone has built a similar idea before (set searchPriorBuilds: true), or to scope timeline / prize-pool / chain fit.' It does not explicitly state when not to use it, but the context is clear and adequate for decision-making.
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 read-only and idempotent. The description adds that a score of 85+ shortens manual DD later, and reinforces the excerpt-only rule. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, and every sentence adds value. No fluff.
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 presence of an output schema, the description adequately explains the tool's behavior and output (breakdown + recommendations). Sufficient 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 baseline is 3. The description repeats what the schema already says about files[].excerpt but does not add new semantic meaning 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 runs a DD pre-screen on Web3 projects, scoring against five dimensions, and returns a breakdown plus recommendations. This is specific and distinguishes it from siblings like apex_code_review or apex_fund_match.
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: extract short excerpts locally and pass as files[].excerpt, with a warning not to transmit full file contents. This tells the agent exactly how to use 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?
Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds behavioral details: runs in sandbox, async for large repos, limited to 3 submissions per day, and returns audit_id. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, front-loading the main purpose and then detailing behavior, usage, and limitations. Every sentence adds necessary information.
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 (multiple input modes, async behavior, output with score and findings), the description covers all key aspects: input types, processing steps, output format, async behavior, and daily limit. Output schema exists, but description explains return values sufficiently.
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 descriptions for all three parameters. The description adds context: mutually exclusive parameters, usage scenarios (repo vs source vs audit_id), and clarifies that github_url clones repo and analyses Solidity/Rust. This adds semantic value 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 runs a preliminary security audit on smart contracts, accepts GitHub URL or pasted Solidity source, runs static analysers and AI review, and returns a score and findings. It is specific and distinguishes from sibling tool names.
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 'use this when asked to audit, review, or assess the security of a project's contracts or on-chain code.' It also provides context on when not to use (not a substitute for professional audit) and notes async behavior for large repos.
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 provide limited info (readOnlyHint=false, etc.). The description adds critical behavioral details: it resets the per-token request counter, enables retrying the original tool call, and is gate-immune. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, efficiently front-loaded with the core purpose. Every sentence adds essential information without 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?
Given the tool's simplicity (one parameter, straightforward purpose) and the presence of an output schema (not shown but indicated), the description fully covers what an agent needs to know: purpose, usage, parameter handling, and behavioral outcomes.
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 description coverage is 100% for the single 'code' parameter. The description adds value by instructing to 'submit verbatim' and noting backend matching, which goes beyond the schema 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 that the tool resets the Apex Copilot verification gate after obtaining a code, with a specific verb 'Reset' and resource 'verification gate'. It is not a tautology and distinguishes from sibling tools by explaining gate-immune behavior.
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 tells when to call ('once the user has either completed the verify procedure... and shared the resulting code'), explains the effect (counter resets, retry original call), and states the endpoint is gate-immune, providing clear usage context and exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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