artefact-mcp-server

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap between detect_signals and score_pipeline_health, as both detect signals. However, they are focused on different aspects (signal-only vs. comprehensive health), so ambiguity is low.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern in snake_case, with only minor deviations like 'qualify' (single verb) and 'run_rfm' (verb+acronym). Overall, the pattern is predictable and clear.
Tool Count5/5
With 7 tools, the server is well-scoped for its domain of GTM analytics and pipeline management. Each tool provides a distinct function without redundancy, earning its place in the set.
Completeness4/5
The tool surface covers core GTM analysis workflows—engine analysis, signal detection, constraint identification, proposal creation, prospect qualification, RFM analysis, and pipeline health. Minor gaps exist, such as no tool for applying changes or performing what-if analysis, but these are not critical for the stated analytical purpose.
Average 4.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under Business Source License 1.1.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context like scanning for 6 signal types and returning specific fields, but does not reveal additional side effects or limitations beyond what annotations provide. 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?
The description is concise yet informative: a clear purpose statement, a bullet list of signals, and structured args/returns. Every sentence earns its place, and the most important info 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 detects 6 signal types with return fields, the description covers the key aspects: what signals, what each signal includes, source options, and return structure. It is fairly complete, especially with an output schema available. Minor missing details like pagination or count limits, but still strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully explain parameters. It does so excellently: it details the source parameter (auto vs hubspot vs sample) and pipeline_id as optional filter. This adds significant meaning beyond the bare 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 scans pipeline data for all 6 specific signal types and returns structured findings, with a list of signals. This distinguishes it from sibling tools like 'analyze_engine' or 'qualify', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the source parameter options (auto, hubspot, sample) but provides no explicit guidance on when to use this tool versus alternatives like 'analyze_engine' or 'score_pipeline_health'. No when-not-to-use or exclusion criteria are mentioned.
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 goes beyond annotations by stating the tool only outputs a proposal for human review and details the proposal components. This aligns with readOnlyHint and adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, list of components, parameter details, and return value. It is front-loaded and each part serves a purpose.
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 an output schema exists and the description covers all parameters and return type, it is fairly complete. The term 'GTM OS anatomy' may be jargon but does not severely impact completeness.
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?
Despite 0% schema coverage, the description lists and explains all parameters with examples for entity_type and signal_type, providing meaning beyond the raw 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 that the tool drafts a GTM commit proposal and explicitly says it does NOT apply the change. It specifies the components and distinguishes itself from sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies its use for proposing changes, it does not explicitly compare with alternatives or state when to use this tool versus siblings like analyze_engine or identify_constraint.
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 indicate readOnlyHint=true and destructiveHint=false, which is reinforced by the description's focus on analysis and output generation. The description adds context about data source options (auto, hubspot, sample) and return structure, which further clarifies behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear summary, output explanation, and parameter details. It is front-loaded with the tool's purpose and avoids redundancy, though the parameter details could be condensed slightly.
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 existence of an output schema (though not detailed here), the description covers inputs, outputs, and key behavioral aspects. It lacks error handling or edge-case guidance but is sufficient for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter names with defaults (0% description coverage). The description compensates fully by explaining each parameter's meaning, options (e.g., 'auto', 'hubspot', 'sample' for source), and purpose, which is critical for correct 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?
The description clearly states the tool runs RFM analysis on client data, detailing scoring, segmentation, ICP extraction, and win/loss detection. This differentiates it from sibling tools like analyze_engine or qualify, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it instead of alternatives. Users can infer it is for customer purchase behavior analysis, but no direct guidance on context or exclusions is provided.
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 mark the tool as readOnlyHint=true and idempotentHint=true, and the description confirms it is a scoring operation returning JSON, with no destructive actions. It adds context about the model structure and scaling constraints, and mentions the API key requirement for company_id, providing behavioral clarity 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?
The description is well-structured with a clear first sentence stating the purpose, then breaking down the model and input options. It is reasonably concise, though the list of company_data keys could be shortened or referenced from an external source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists), the description covers inputs, model components, and return values adequately. It mentions constraint context and recommended action, but does not elaborate on error handling or detailed output schema (though the schema is separately defined). Overall, it provides sufficient context for an AI 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?
With 0% schema description coverage, the description compensates well by detailing company_data with example keys and explaining company_id and scoring_config. However, scoring_config is described only as 'override default scoring parameters' without listing possible keys or formats, leaving some ambiguity.
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 scores a prospect against the Artefact 14.5-point ICP model, specifying the three fit components (Firmographic, Behavioral, Strategic) and the return values. It distinguishes itself from sibling tools like run_rfm and score_pipeline_health by focusing on ICP qualification.
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 clear instructions on input options: use company_id (with HubSpot API key) or company_data (JSON string) and optional scoring_config. It lists example keys for company_data. However, it does not explicitly state when to use this tool over alternatives or when not to use it.
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 indicate read-only and idempotent behavior. Description adds details like using HubSpot or sample data, and returning JSON. 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?
Description is well-structured with clear sections (Args, Returns) and front-loaded purpose. Concise but covers all key aspects 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 presence of an output schema (not shown but referenced), description covers inputs and outputs sufficiently. Lists return fields: health score, velocity, conversion rates, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description comprehensively explains all three parameters: pipeline_id (optional, filter), source (hubspot/sample/auto), and exit_criteria (optional JSON). Adds meaning beyond basic types.
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 analyzes pipeline health with velocity metrics, signal detection, and exit criteria testing. It distinguishes from siblings like analyze_engine or qualify by focusing on health scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains what the tool does but does not explicitly state when to use it over siblings or provide exclusions. Usage context is implied through functionality.
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. The description adds value by detailing the engine stages, metrics, and return JSON structure (engine definition, health score, etc.), 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?
The description is approximately 110 words, with a clear bulleted structure for engine stages. It is front-loaded with the main purpose. While efficient, the bullet list could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three engines), the description covers inputs, outputs, and examples well. It does not reference sibling tools, but the output schema existence reduces the need to explain return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter: engine_type options ('growth', 'fulfillment', 'innovation'), source options ('auto', 'hubspot', 'sample') with fallback logic, and pipeline_id as optional. This fully compensates for the schema deficiency.
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 analyzes a Value Engine (Growth, Fulfillment, or Innovation), listing stages and metrics for each. This specific verb+resource purpose distinguishes it from sibling tools like score_pipeline_health or identify_constraint.
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 clear context by enumerating the three engine types, implying when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, which could help with sibling differentiation.
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 provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by explaining the analysis logic and return structure. It could be more explicit about being a non-modifying analysis, but annotations sufficiently cover the safety profile.
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 around 130 words, well-structured with an opening purpose statement, analysis method, parameter details, and return description. Every sentence adds value, and the front-loaded style ensures key information is immediate.
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 complex tool with 3 parameters, multiple data sources, and analytical output, the description covers purpose, methodology, parameters, and return value. An output schema exists, but the description still summarizes the JSON structure appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It does so comprehensively: source options (auto, hubspot, sample) with behavior, and optional pipeline_id and quota with their purposes. This fully compensates for the lack of schema 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 identifies the dominant scaling constraint bottlenecking revenue, using specific verb 'identify' and resource 'constraint'. It details the analysis of pipeline metrics and four constraint types, distinguishing it from sibling tools like analyze_engine or score_pipeline_health.
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 explains parameter options (source values, optional pipeline_id, quota) and when to use each data source. However, it does not explicitly state when not to use this tool or provide direct comparisons to sibling tools, though the purpose is distinct enough.
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:

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

Score Badge

Copy to your README.md:

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

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/artefactventures/artefact-mcp-server'

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