What can you do with this server?

This server provides AI-accessible tools to retrieve Jake Gaylor's professional information and perform recruitment-related tasks. You can: * Access his resume (text and URL), LinkedIn, GitHub, website (URL and content), and structured candidate preferences (role type, level, location, remote, work authorization, compensation, availability). * Use AI-powered tools: ask questions about Jake (LLM with fallback), generate tailored interview questions (by type, focus, difficulty), and assess role fit (graded evaluation with strengths, gaps, and suggested questions). * Connect via MCP (Streamable HTTP/SSE) or A2A agent (JSON-RPC with automatic discovery). * View a human-readable resume webpage and a plain-text LLM-friendly version. * Schedule calls through Cal.com integration and relay messages to his email.

Which integrations are available for this server?

Allows sending emails to Jake via the contact_candidate tool, using Mailgun as the email provider. Provides LLM capabilities for the about-jake skill, enabling answers to questions about Jake's experience using OpenAI models. Allows sending emails to Jake via the contact_candidate tool, using Resend as the email provider.

How do I use jakegaylor-com-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jakegaylor-com-mcp-server echo 'Hello, MCP!'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

jakegaylor-com-mcp-server

by jhgaylor

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

ai.jakegaylor.com

An Express + TypeScript server that makes Jake Gaylor legible to AI systems. One deployment serves four interfaces to the same underlying resume and bio:

A webpage (GET /) for humans
Plain-text context (GET /llms.txt) for LLMs and crawlers
An MCP server (/mcp) for AI clients a human has configured
An A2A agent (/a2a + agent card) for agents that discover the site on their own

The resume content is fetched from jakegaylor.com/resume.json at boot and rendered to markdown, so every interface stays current without hand-editing.

Endpoints

Endpoint	What it serves
`GET /`	Webpage
`GET /llms.txt`	Resume + core beliefs as plain text
`POST /mcp` (+ `GET`/`DELETE`)	MCP over Streamable HTTP
`GET /sse` + `POST /messages`	MCP over legacy SSE transport
`GET /.well-known/agent-card.json`	A2A agent card (v1.0, with v0.3 translation for legacy clients), JWS-signed when a key is configured
`GET /.well-known/jwks.json`	Public keys for verifying the card signature
`POST /a2a`	A2A JSON-RPC endpoint (v1.0 + v0.3 compat)

Related MCP server: Echo MCP Server

MCP

Built on @jhgaylor/candidate-mcp-server. Tools exposed:

get_resume_text, get_resume_url, get_linkedin_url, get_github_url, get_website_url, get_website_text, contact_candidate (emails Jake), generate_interview_questions, assess_role_fit, get_candidate_preferences (structured screening data — see src/preferences.ts), get_availability + book_intro_call (Cal.com-backed scheduling with the same pending-confirmation and daily-cap guardrails as the A2A skill)

Connect a client to https://ai.jakegaylor.com/mcp, or run locally over stdio with npx @jhgaylor/me-mcp.

A2A

An A2A v1.0 agent built on @a2a-js/sdk, with the v0.3 compatibility layer enabled — clients that send no A2A-Version header are treated as v0.3 by the protocol, and most deployed clients still speak it. The card advertises both versions on the same URL.

Skills:

about-jake — answers questions about Jake's experience using a cheap LLM grounded in the resume, bio, and screening data. If no LLM key is configured or the call fails, it falls back to returning the complete resume as markdown, so the skill contract holds either way.
candidate-preferences — structured screening data (role types, level, location, relocation, remote, work authorization, comp stance, availability, resume links) returned as a JSON data part plus markdown. Triggered by screening/logistics keywords or metadata.skill. Values live in src/preferences.ts.
assess-role-fit — send a job description (JD: prefix, or any long JD-shaped text) and get an honest LLM-graded fit assessment: verdict, strengths with resume citations, gaps named plainly, logistics check, and suggested interview questions. Falls back to returning the resume when no LLM is available.
schedule-intro-call — scheduling-intent messages return open slots from the self-hosted Cal.com (cal.jakegaylor.com, public booking endpoints — no licensed API needed); BOOK: <slot> | <email> | <name> | <note> creates a booking. Guardrails: bookings require Jake's confirmation (Cal.com-native), explicit BOOK: prefix for the side effect, and a daily attempt cap. Config via CAL_* env vars in src/calcom.ts.
connect-via-mcp — messages mentioning MCP get connection instructions for the richer MCP interface.
contact-jake — messages starting with CONTACT: are relayed to Jake by email. Only that explicit prefix (or metadata.skill = "contact-jake") triggers mail.

Example:

curl -X POST https://ai.jakegaylor.com/a2a \
  -H "Content-Type: application/json" -H "A2A-Version: 1.0" \
  -d '{"jsonrpc":"2.0","id":1,"method":"SendMessage","params":{"message":{
        "messageId":"m1","role":"ROLE_USER",
        "parts":[{"text":"What is Jake's experience with Kubernetes?"}]}}}'

Configuration

Env var	Purpose
`PORT`	HTTP port (default 3000)
`RESEND_API_KEY`	Email via Resend SMTP (preferred when set)
`EMAIL_FROM`	From-address for Resend (domain must be verified in Resend)
`MAILGUN_API_KEY`	Email via Mailgun (fallback when Resend is not configured)
`OPENROUTER_API_KEY`	LLM for `about-jake` via OpenRouter (preferred when set)
`OPENAI_API_KEY`	LLM for `about-jake` via OpenAI directly (fallback)
`LLM_MODEL`	Model override (default `openai/gpt-5.4-nano` on OpenRouter, `gpt-5.4-nano` on OpenAI)
`A2A_BASE_URL`	Public base URL baked into the agent card (default `https://ai.jakegaylor.com`)
`A2A_SIGNING_KEY_JWK`	Private ES256 JWK (with `kid`) that signs the agent card; unset serves an unsigned card
`POSTHOG_API_KEY`	Server-side agent-traffic analytics (card fetches, MCP/A2A requests, skill routing); analytics are disabled without it
`POSTHOG_HOST`	PostHog endpoint (default `https://us.i.posthog.com`)

With no email keys set, contact_candidate/contact-jake report failure gracefully. With no LLM keys set, about-jake is fully deterministic.

Development

npm install
npm run build        # tsc
npm run dev          # stdio transport, auto-reload
npm run dev:web      # HTTP transport on :3000, auto-reload

src/
  ├── index.ts           # Entry point; picks stdio or HTTP transport
  ├── express.ts         # HTTP server: web, MCP, A2A mounting
  ├── a2a.ts             # A2A agent card, executor, skills
  ├── preferences.ts     # Structured screening data (edit values here)
  ├── stdio.ts           # STDIO transport for MCP
  ├── config.ts          # Server + candidate config; fetches resume at boot
  ├── resumeMarkdown.ts  # JSON Resume → markdown renderer
  └── types.ts           # Shared types

Deployment

Pushes to main trigger a GitHub Actions build of a multi-arch Docker image (jhgaylor/jake-gaylor-com-mcp-server). The workflow then pins k8s/kustomization.yaml to the new sha-<commit> tag and commits it back; Flux watches the repo and rolls the deployment on the home-cloud k3s cluster. Runtime secrets come from Infisical via an InfisicalSecret (see k8s/infisicalsecret.yaml) and land in the pod through envFrom.

License

MIT

Available Tools

9 tools

assess_role_fitC

Assess Jake Gaylor's fit for a specific role based on job description

ParametersJSON Schema

Name	Required	Description
`job_title`	Yes	Title of the job position
`job_description`	Yes	Full job description text
`key_requirements`	Yes	Comma-separated list of key requirements for the role

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the tool's purpose without describing side effects, output format, data sources, or authorization needs. Agents cannot infer whether this is read-only or what the assessment entails.

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 a single sentence with no fluff, making it concise. However, it could be slightly more informative without sacrificing brevity, such as mentioning the output or data sources.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description lacks critical context. It does not explain how the assessment is computed, what the result looks like, or how it relates to sibling tools that provide candidate data. The tool is too vague for reliable 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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the parameter names and schema descriptions. The parameter descriptions are sufficient but the tool's description does not enhance understanding of how parameters influence the assessment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'assess' and the resource 'fit for a specific role based on job description', distinguishing it from sibling tools like get_resume_text or generate_interview_questions. However, the specific reference to 'Jake Gaylor' may limit generality or confuse agents about its applicability to other candidates.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., candidate data availability) or situations where this tool would be inappropriate. Agents lack context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_interview_questionsC

Generate tailored interview questions for Jake Gaylor

ParametersJSON Schema

Name	Required	Description
`difficulty`	Yes	Target difficulty level for questions
`focus_areas`	Yes	Comma-separated list of technical areas to focus questions on
`interview_type`	Yes	Type of interview to generate questions for

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to mention whether questions are saved, if the operation is idempotent, or any side effects. The description is purely a statement of function without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no fluff, but it is arguably too minimal. While concise, it lacks structure (e.g., no breakdown of inputs or outputs). It conveys the core action but sacrifices detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and only three parameters, the description should explain what the generated output looks like (e.g., format, number of questions). It omits this entirely, leaving the agent uninformed about the return value and overall behavior.

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 coverage is 100%, so baseline is 3. The description adds no additional meaning for parameters beyond their schema definitions (e.g., what 'tailored' means in terms of focus areas or difficulty). It does not enhance understanding of parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'generate' and the resource 'tailored interview questions for Jake Gaylor', making the tool's purpose clear. However, it does not explicitly differentiate from siblings like 'assess_role_fit', which could overlap in use cases. The standalone purpose is strong but lacks sibling distinction.

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 provides no guidance on when to use this tool versus alternatives (e.g., assess_role_fit, get_resume_text). There are no hints about prerequisites, best practices, or when not to invoke. This forces the agent to guess context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_candidate_preferencesC

Structured screening and logistics data for Jake Gaylor: role types, level, location, relocation, remote preference, work authorization, compensation stance, availability, and machine-readable resume links. Returns JSON.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only mentions return format (JSON) but does not disclose whether data is static, fetched live, or tied to the named candidate. No mention of permissions, freshness, or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence but over-packed with a comma-separated list. Could be split into bullet points or clearer structure. Lacks paragraph breaks or emphasis.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema and with zero parameters, the description must fully explain the tool's behavior. It mentions a specific candidate (Jake Gaylor) without clarifying if this is a demo or a persistent lookup. No details on data source, update frequency, or scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. The description adds value by enumerating returned fields (role types, level, location, etc.), which compensates for the lack of parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states it returns structured data for 'Jake Gaylor', which is clear in content but confusing because the tool name implies a generic candidate fetch. Sibling tools suggest parameterization, but this tool has no parameters, making its scope ambiguous.

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?

No guidance on when to use this tool versus siblings like get_resume_text or assess_role_fit. The description does not explain context or alternatives, leaving the agent to infer from tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_github_urlA

Get the GitHub URL of the candidate Jake Gaylor

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It describes a simple read operation without side effects, but does not elaborate on authentication or output format.

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?

A single sentence conveys the entire purpose with no extraneous words. It is front-loaded and packs all 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 simplicity (no parameters, no output schema) and the context of sibling URL getters, the description is sufficiently complete 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty, so the description adds no param details. By convention, a score of 4 is appropriate for tools without parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Get', the resource 'GitHub URL', and identifies the specific candidate 'Jake Gaylor', distinguishing it from sibling tools for other platforms.

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?

No explicit when-to-use or alternative guidance is provided, but the singular purpose is clear from the context of sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_linkedin_urlA

Get the LinkedIn URL of the candidate Jake Gaylor

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states the basic function without disclosing side effects, error behavior, or response format. Minimal transparency.

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?

Single sentence, no waste. Every word is necessary and immediately conveys the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description is clear for a specific candidate, it does not explain why the tool is hardcoded to Jake Gaylor or how it behaves if used for other candidates. Given no output schema, more context on return values would help.

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?

There are no parameters, and schema coverage is 100% (empty). Per guidelines, 0 parameters gets a baseline of 4. The description adds no param info, but none is needed.

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 verb 'Get' and the resource 'LinkedIn URL of the candidate Jake Gaylor', which distinguishes it from siblings that retrieve different resources (e.g., resume, GitHub).

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?

No guidance is provided on when to use this tool versus alternatives like get_github_url or get_resume_url. The agent receives no context about selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_resume_textA

Get the resume text of the candidate Jake Gaylor

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states what the tool does without disclosing behavioral traits like error handling, output format, or side effects. The agent lacks insight into tool behavior beyond the basic function.

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 concise sentence with no extraneous information, efficiently conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description is minimal. It does not describe the return format or handling of missing resume text. While adequate for a trivial tool, it lacks completeness for an agent to fully understand behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is 100% vacuously. With no parameters, the description need not add parameter meaning; a baseline score of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get', the resource 'resume text', and specifies the candidate 'Jake Gaylor', making it highly specific and distinguishable from siblings like get_resume_url.

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?

There is no guidance on when to use this tool versus alternatives such as get_resume_url or get_linkedin_url. The description does not mention any context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_resume_urlB

Get the resume URL of the candidate Jake Gaylor

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the action without disclosing any behavioral traits (e.g., whether it requires authentication, is read-only, or the format of the URL). This leaves the agent with minimal understanding of side effects or constraints.

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 concise sentence with no wasted words. It is front-loaded and efficiently conveys the core 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 no output schema and no parameters, the description is largely complete for the simple action it describes. However, it does not explain why the candidate name is hardcoded or if the tool is meant for a specific scenario, leaving a slight gap in context.

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?

There are no parameters, so the schema coverage is 100% vacuously. According to guidelines, 0 parameters earns a baseline of 4. The description adds no parameter details because none exist, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Get', the resource 'resume URL', and the specific candidate 'Jake Gaylor'. It distinguishes from sibling tools like get_resume_text by explicitly naming the output format and candidate, though the hardcoded name limits generality.

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?

No guidance on when to use this tool versus alternatives like get_linkedin_url or get_resume_text. The description does not provide context for when this specific URL is needed or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_website_textC

Get the website text of the candidate Jake Gaylor

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No disclosure of side effects, failure modes, or required permissions. With no annotations, the description carries full burden but only states the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, but overly specific and incomplete. It is not efficiently written for general use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description does not explain return format or behavior. Insufficient for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the description provides the entire meaning. Baseline for 0 params is 4; description adds value by stating the tool's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves website text, distinguishing it from siblings like get_resume_text. However, it is overly specific to candidate 'Jake Gaylor', which may not be intended.

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?

No guidance on when to use this tool vs alternatives (e.g., get_resume_text for resume). No exclusions or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_website_urlB

Get the website URL of the candidate Jake Gaylor

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks behavioral details such as authentication requirements, side effects (e.g., read-only), or error handling (e.g., if no website exists).

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 a single sentence of 10 words, which is concise and front-loaded with the action. However, it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the zero-parameter complexity, the description is minimal but adequate. It does not mention the return format or possible error states, but the pattern is clear from the tool name and siblings.

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?

The input schema has zero parameters, so the description does not need to document them. Baseline is 4 per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the website URL for the candidate Jake Gaylor. It distinguishes from sibling tools like get_resume_url or get_website_text by specifying the resource.

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?

No guidance on when to use this tool versus alternatives such as get_website_text or other URL retrieval tools. The description does not mention prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.3.0Jul 29, 2026
- First observedassess_role_fit
- First observedgenerate_interview_questions
- First observedget_candidate_preferences
- First observedget_github_url
- First observedget_linkedin_url
- First observedget_resume_text
- First observedget_resume_url
- First observedget_website_text
- First observedget_website_url

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-29 01:35 across 9 tools

Disambiguation5/5

Each tool retrieves a distinct piece of information or performs a unique analysis (e.g., resume text vs. LinkedIn URL vs. interview question generation), with no overlap.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern (e.g., get_resume_text, get_linkedin_url, generate_interview_questions), making them predictable.

Tool Count5/5

9 tools is well-suited for a focused personal-profile server, covering all needed operations without excess or deficiency.

Completeness5/5

The server comprehensively covers retrieving personal info, URLs, text, and conducting role assessments and interview prep, with no obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
11
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
1
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Parallel Task MCP AOAuth
ai.parallel
An MCP server for deep research or task groups
Autonomous Agents Agent Orchestration Research & Data
4415

Related MCP Servers

MCP Everything
Code Execution Testing & QA Tools
s2005
A
license
Not graded
quality
D
maintenance
A test server implementing all features of the MCP protocol, including prompts, tools, resources, and sampling, designed for testing MCP clients rather than practical applications.
Updated a year ago (2025-05-24 08:55 UTC)
MIT
Echo MCP Server
Developer Tools
somacaru
F
license
Not graded
quality
D
maintenance
A simple demonstration MCP server that provides an echo tool and resource for learning how to build MCP servers. Serves as a starting point and template for creating custom MCP server implementations.
Updated a year ago (2025-09-29 05:44 UTC)
1
-
Basic MCP Server
Developer Tools
gurdasnijor
A
license
Not graded
quality
D
maintenance
A minimal demonstration server showcasing MCP protocol capabilities including tools, resources, and prompts with basic examples like hello world functionality.
Updated a year ago (2025-10-28 01:34 UTC)
1 npm
MIT
mcpv3e
Developer Tools
IamFreak10
F
license
Not graded
quality
C
maintenance
MCP server providing greeting and echo tools for testing and demonstration.
Updated 4 months ago (2026-05-12 14:39 UTC)
-