Search for and import stock photos from Pexels into the YesHello media library.
YesHello is a platform for creating digital business cards, lead capture forms, and service listings. This MCP server gives AI assistants (Claude, Cursor, VS Code, ChatGPT, and any MCP-compatible client) full control over building and managing your online business presence.
Give AI a website URL, and it builds your complete digital business card in under 2 minutes.
Related MCP server: Demaciains MCP Server
63 tools across 8 categories: Cards, Forms, Submissions, Listings, Media, Interactive, Account, Skills
Build from URL - AI scrapes your website and creates a card with your real content
Live editing - if you have the builder open, watch the AI build your card in real-time
Stock photo search - search and import from Pexels directly
Web scraping - read any URL and extract clean markdown content
Browser control - AI can highlight elements, give guided tours, fill inputs, navigate pages
Progressive skills - AI loads only the knowledge it needs, when it needs it
4 themes - Minimal, Professional, Wave, Cinematic
20+ field types - hero, about, gallery, FAQ, social links, action buttons, video, forms, services, and more
/plugin marketplace add yeshello-app/mcp
/plugin install digital-business-card@yeshelloThen just say: "Build me a digital business card from https://mywebsite.com"
The plugin includes the skill + MCP server connection. You'll be guided through connecting your account on first use.
Go to Settings > Connectors > Add Connector
Enter URL: https://yeshello.app/api/mcp
Click Connect and log in to authorize
Start chatting - try "Build me a business card from https://mywebsite.com"
claude mcp add yeshello --transport http https://yeshello.app/api/mcpAdd to your MCP config file:
{
"mcpServers": {
"yeshello": {
"url": "https://yeshello.app/api/mcp"
}
}
}No API key needed - OAuth handles authentication automatically.
Try these after connecting:
Prompt | What happens |
"Build me a business card from https://mywebsite.com" | AI scrapes your site, extracts content, imports images, builds complete card |
"Create a contact form with name, email, phone, and message" | AI creates and publishes a lead capture form with webhook delivery |
"Add a services listing for my photography business" | AI creates a service listing with pricing and booking CTAs |
"Search for professional headshot photos" | AI searches Pexels and imports stock photos to your media library |
"Show me around the card builder" | AI highlights UI elements and gives you a guided tour |
"What cards do I have?" | AI lists your existing cards with status and links |
Category | Count | What it does |
Cards | 16 | Create, edit, publish digital business cards with 20+ field types across 4 themes |
Forms | 8 | Build lead capture forms with 7 field types and webhook delivery |
Submissions | 6 | View form submissions and webhook delivery logs |
Listings | 12 | Create service, product, property, and event listings with items and CTAs |
Media | 8 | Upload images, search Pexels stock photos, scrape web content, manage folders |
Interactive | 4 | Browser highlights, guided tours, page navigation, input filling |
Account | 2 | View account info and usage quotas |
Skills | 6 | On-demand reference guides the AI loads when needed |
The MCP server uses OAuth 2.0 with PKCE (S256) via Client ID Metadata Documents (CIMD). No API keys to manage - your AI client handles the OAuth flow automatically.
When you connect for the first time:
A browser window opens to yeshello.app/oauth/authorize
Log in (or register) with your YesHello account
Click Approve on the consent screen
You're connected - tokens refresh automatically
The MCP server is a stateless pass-through - it forwards requests to the YesHello API and returns results
No additional data is collected beyond what the platform stores
OAuth tokens are stored as SHA-256 hashes
You can revoke access anytime from Settings > AI & API
Full privacy policy: yeshello.app/page/privacy-policy
YesHello has a free tier - connect the MCP server, build your first card, and publish it at no cost. Upgrade for more cards, custom domains, teams, and premium features.
See yeshello.app/pricing for details.
This repo includes installable skills that work with Claude Code, OpenAI Codex, Cursor, Gemini CLI, and any tool supporting the Agent Skills open standard.
Build a complete digital business card from a website URL in one conversation. The skill handles the entire pipeline: scrape website, extract content, search stock photos, import images, create card, publish.
Install:
# Copy to your personal skills directory
cp -r skills/digital-business-card ~/.claude/skills/
# Or for a specific project
cp -r skills/digital-business-card .claude/skills/Use:
/digital-business-card https://mywebsite.comOr just ask naturally: "Build me a digital business card from https://mywebsite.com"
Requires the YesHello MCP server to be connected (https://yeshello.app/api/mcp).
Documentation: yeshello.app/docs/mcp-connector
Email: hello@yeshello.app
This repository contains documentation and configuration for the YesHello MCP server. The server itself is a hosted service at yeshello.app/api/mcp. The documentation in this repository is MIT licensed.
Create a new digital business card. Requires connection to the hosted server.
| Name | Required | Description | Default |
|---|---|---|---|
| themeId | No | Theme: professional, minimal, wave, cinematic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior. The description adds the server connection requirement, but does not disclose other behaviors like idempotency, failure modes, or side effects. It provides adequate but minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, both front-loaded. Every sentence adds value: the first states the action and resource, the second states a prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose and a prerequisite but lacks details on default behavior for missing parameters and what the tool returns. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter 'themeId' already described in the schema. The description adds no extra meaning beyond the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'digital business card', which is distinct from all sibling tools that are read-centric. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a prerequisite (server connection) but does not explicitly state when to use this tool versus alternatives, nor provides exclusions. Context implies creation use case, but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated user profile. Requires connection to the hosted server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint; description adds server connection requirement but no further behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters or output schema; description sufficiently covers purpose and a key prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100%; description correctly offers no additional parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the authenticated user profile' – a specific verb and resource that distinguishes from siblings like create_card or get_help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'Requires connection to the hosted server', giving a clear prerequisite; no need for alternatives given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a compact index of available skills and quick-start commands. This is a hosted server - connect at https://yeshello.app/api/mcp for all 63 tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds minimal behavioral context beyond the return type, not contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences concise, front-loading the purpose and adding a single contextual detail about the server. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description explains the return value adequately. It could be more precise about the index structure but is sufficient for a help overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description does not need to add parameter information. The baseline score for no params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact index of available skills and quick-start commands, which is a specific verb and resource distinct from sibling tools that perform individual actions like creating cards or getting accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to get an overview, but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape URLs and return clean markdown. Requires connection to the hosted server.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to scrape (max 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the bar is lower. The description adds the requirement of server connection and implies non-destructive scraping. However, it doesn't disclose rate limits, error handling, or behavior for non-HTML content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences without any filler. Every part adds value: the action, output format, and a key prerequisite. It is front-loaded with the main functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scraping tool with one parameter and no output schema, the description covers the essence. It mentions the output format and a critical requirement. However, it could optionally note the max 5 URLs (present in schema) or error scenarios, but it remains largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the 'urls' parameter, and the description merely echoes 'Scrape URLs'. No additional meaning is provided beyond what the schema states, such as URL format or constraints. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes URLs and returns clean markdown, which is specific and distinguishable from siblings like create_card or get_account. The verb 'scrape' and the resource 'URLs' are well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a prerequisite (connection to hosted server) but provides no guidance on when to use this tool versus alternatives, nor any exclusion criteria. Among siblings, none appear similar, but explicit usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Play a guided tour with highlights and optional clicking. Requires connection to the hosted server.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already imply external dependencies (openWorldHint=true). Description adds the server requirement, but does not disclose additional behaviors like state changes or interactive elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with essential information. No redundant words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks parameter documentation and does not describe return behavior. Given one required parameter with complex nested objects, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter descriptions in schema or description. The 'steps' array structure (selector, tooltip, click) is completely unexplained, forcing the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific action ('play a guided tour') with a clear resource ('tour'). Distinct from sibling tools like get_account or search_pexels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite ('requires connection to hosted server') but does not specify 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.
Search free stock photos on Pexels. Requires connection to the hosted server.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait of requiring a server connection, which is beyond the readOnlyHint=true and destructiveHint=false annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose, and contains no superfluous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only behavior), the description is largely complete. It could optionally mention result format or pagination, but is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter with a clear description 'Search term'. The description does not add any additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search free stock photos on Pexels', providing a specific verb and resource. It distinguishes from sibling tools like create_card or get_account, which have no relation to stock photos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires connection to the hosted server', which is a prerequisite, but does not explicitly state when to use or not use this tool versus alternatives. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_cardget_accountget_helpget_page_contenthighlight_toursearch_pexelsScored across 6 tools
Each tool targets a distinct function: card creation, account retrieval, help index, page scraping, guided tours, and stock photo search. No two tools have overlapping purposes, so an agent can clearly distinguish them.
All tool names follow the verb_noun pattern in snake_case (e.g., create_card, get_account, search_pexels). The naming convention is uniform and predictable.
With 6 tools, the count falls well within the 3–15 range considered appropriate. Each tool serves a distinct purpose and none seem redundant or missing for a starter set.
The tool set lacks coverage for the apparent core domain of digital business cards: only create and get are present; no update, delete, or list operations are provided. Additionally, several tools (e.g., search_pexels, get_page_content) are unrelated to this domain, making the surface feel incomplete and unfocused.
AI agent website builder. Create and publish link-in-bio sites via MCP or REST API.
Build, edit, stock, and publish Social AI websites and storefronts via AI chat.
Build, edit, and publish real websites and online stores by chatting with your AI assistant.
8-tool AI web intelligence suite: search, scrape, screenshot, SEO, docs, crypto, code.
