Thomas Anglero Speaker MCP

Server Details

Thomas Anglero, Strategic AI Advisor & keynote speaker: bio, topics, booking, inquiry tools.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 92.4% over 54 days
Last Tested: 2026-10-10 05:43
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-21 15:00 across 5 tools

Disambiguation5/5

Each tool targets a distinct purpose: availability guidance, booking logistics, speaker bio, topic descriptions, and inquiry submission. There is no overlap or ambiguity between them.

Naming Consistency5/5

All informational tools follow a consistent get_ noun pattern (get_availability_guidance, get_booking_info, get_speaker_profile, get_speaking_topics), and the single action tool uses submit_speaking_inquiry. The naming is predictable and uniform.

Tool Count5/5

Five tools is well-scoped for a speaker information and inquiry server. Each tool earns its place without unnecessary redundancy or missing core functionality.

Completeness5/5

The surface fully covers the apparent domain: providing all key pre-inquiry information and a complete submission path. The absence of a live availability calendar is intentional and documented, so there are no dead ends.

Available Tools

5 tools

get_availability_guidanceGet availability guidanceA

Read-only

Inspect

How availability is confirmed. No live calendar is published. Availability for a date is confirmed on inquiry, typically within two business days.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description adds key behavioral details: there is no live calendar, and availability is confirmed on inquiry within two business days. This context helps the agent understand the tool's limitations.

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 with three short sentences, front-loading the key purpose. Every sentence adds essential information with no 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 has no parameters and no output schema, the description fully covers what the agent needs to know: the purpose and behavior. It is complete for a tool that provides guidance text.

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 no parameters, and schema description coverage is 100%. Since there are no parameters to document, the description does not need to add parameter semantics, and the baseline score of 4 applies.

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 what the tool does: it explains how availability is confirmed, including that no live calendar is published and confirmation takes two business days. This distinguishes it from sibling tools like 'get_booking_info' which likely retrieves specific booking details.

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 implies that this tool is for understanding the availability confirmation process rather than checking live availability or making an inquiry, but it does not explicitly state when to use this tool over siblings like 'submit_speaking_inquiry'.

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

get_booking_infoGet booking informationA

Read-only

Inspect

How booking works, the formats offered, and how fees are handled. Fees are provided on inquiry, tailored to format and location. Response within two business days.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and description adds that it provides informational content and mentions response time within two business days, which goes 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?

Three sentences, front-loaded with main purpose, no unnecessary words. Highly efficient.

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 parameters and no output schema, description covers the tool's purpose well. Could be improved by indicating whether output is plain text or structured.

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, so schema coverage is 100%. Description doesn't need to compensate. Baseline 4 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?

Description clearly states it explains how booking works, formats, and fees handling. It distinguishes from siblings like submit_speaking_inquiry which is for submission. Could be more specific about the return format.

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?

Implied usage: when user needs to understand booking process or fees. No explicit when-not-to-use or alternatives like get_availability_guidance.

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

get_speaker_profileGet speaker profileA

Read-only

Inspect

Canonical short bio, positioning, notable clients, and links for Thomas Anglero.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

The readOnlyHint annotation already indicates this is a safe read operation. The description adds value by specifying the exact content returned (bio, positioning, clients, links), which goes beyond the annotation.

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, front-loaded sentence that efficiently conveys the tool's purpose and output. No extraneous 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?

For a simple read-only tool with no parameters and no output schema, the description adequately lists the return fields (bio, positioning, clients, links), making it complete for an agent to understand the output.

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 with 100% schema coverage. The description does not need to explain parameters, and the lack of parameters is clearly communicated by the empty 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 returns 'Canonical short bio, positioning, notable clients, and links for Thomas Anglero.' It uses a specific verb ('get') and resource ('speaker profile'), and the sibling tools (e.g., get_speaking_topics, get_booking_info) are clearly distinct topics.

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 when-not-to-use guidance is provided. The description implies usage for obtaining biographical and profile information, but does not differentiate from siblings like get_speaking_topics or get_booking_info.

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

get_speaking_topicsGet speaking topicsA

Read-only

Inspect

The three keynote topics with titles, subtitles, and a one-paragraph description each.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description aligns with the readOnlyHint annotation, confirming it is a read-only operation. It adds value by detailing what data is returned, but does not disclose additional behaviors like caching or prerequisites.

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 sentence that is concise, front-loaded, and contains no unnecessary words. It efficiently communicates the tool's output.

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 simple tool with no parameters and no output schema, the description fully specifies what the tool returns (three topics with titles, subtitles, descriptions). No additional context is needed.

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 no parameters, so the baseline is 4. The schema coverage is 100%, and the description does not need to add parameter semantics.

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 it returns exactly three keynote topics, each with title, subtitle, and a one-paragraph description. This is distinct from sibling tools like get_availability_guidance or get_speaker_profile.

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 does not explicitly state when to use this tool versus alternatives, but it is implied that it is for retrieving keynote topics. No exclusions or alternatives are mentioned.

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

submit_speaking_inquirySubmit a speaking inquiryAInspect

Send a speaking inquiry to Thomas Anglero. Requires six fields: name, email, phone, company or organization, event date, and a free-text message. Fold every other detail into the message in natural language: what Thomas should speak about, event location, format (in person, virtual, or pre-recorded), expected audience size, your role, and budget if any. Writes into the same pipeline as the website form: it records the inquiry and sends the confirmation and notification emails. Thomas replies personally, typically within two business days.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Full name of the person making the inquiry.
`email`	Yes	Contact email address.
`phone`	Yes	Contact phone number, including country code if the event is outside Norway.
`company`	Yes	The company or organization the inquiry is on behalf of.
`message`	Yes	A short free-text description of the event. Fold everything relevant into this one field in natural language: what you would like Thomas to speak about, event location, format (in person, virtual, or pre-recorded), expected audience size, your role at the company, and budget if you have one. Thomas reads this and replies with availability and a tailored proposal.
`website`	No	Leave blank. Anti-spam field.
`event_date`	Yes	Event date, for example "17 February 2027". If the date is not yet fixed, give the intended month or timeframe.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only provide readOnlyHint: false, so the description carries the burden. It discloses side effects: 'records the inquiry and sends the confirmation and notification emails,' and that Thomas replies personally. This goes beyond the annotation and gives the agent a clear model of what happens.

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 appropriately sized, with the action front-loaded and the required fields listed compactly. The extra guidance on the message field is dense but necessary, and the pipeline/reply-time info is placed at the end, earning its place.

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 submission tool with no output schema, the description explains the outcome (record + emails + personal reply) and the typical response time. It also covers the anti-spam field and gives examples of acceptable date formats. Nothing an agent needs to invoke it correctly is missing.

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 the baseline is 3. The description adds meaningful guidance beyond the schema, especially for the message field, explaining that all other details should be folded into it in natural language and listing what to include. It also clarifies the website field as an anti-spam field, which the schema already says but the description reinforces.

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 opens with a specific verb+resource: 'Send a speaking inquiry to Thomas Anglero.' It clearly distinguishes from the sibling get_* tools, which are all retrieval operations, by being the only write/submit tool.

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?

It states the required fields and instructs how to structure the message, and it describes the pipeline and reply time. It doesn't explicitly name alternative tools or say 'use this instead of X,' but the sibling context makes the use case obvious—submitting vs. retrieving.

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.

1 tool updateSep 21, 2026

Changedsubmit_speaking_inquiry1 field changed

changedInput schema / properties / company / description

Previous value: -"The company or organisation the inquiry is on behalf of."New value: +"The company or organization the inquiry is on behalf of."

1 tool updateAug 25, 2026

Changedsubmit_speaking_inquiry4 fields changed

addedInput schema / properties / company

Added value: +{
+  "description": "The company or organisation the inquiry is on behalf of.",
+  "type": "string"
+}

changedInput schema / properties / message / description

Previous value: -"A short free-text description of the event. Fold everything relevant into this one field in natural language: event location, format (in person, virtual, or pre-recorded), the topic or theme you would like Thomas to speak about, expected audience size, the organisation and your role, and budget if you have one. Thomas reads this and replies with availability and a tailored proposal."New value: +"A short free-text description of the event. Fold everything relevant into this one field in natural language: what you would like Thomas to speak about, event location, format (in person, virtual, or pre-recorded), expected audience size, your role at the company, and budget if you have one. Thomas reads this and replies with availability and a tailored proposal."

addedInput schema / properties / phone

Added value: +{
+  "description": "Contact phone number, including country code if the event is outside Norway.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "email",
-  "event_date",
-  "message"
-]New value: +[
+  "name",
+  "email",
+  "phone",
+  "company",
+  "event_date",
+  "message"
+]

1 tool updateJul 13, 2026

Changedsubmit_speaking_inquiry12 fields changed

removedInput schema / properties / audience_size

Removed value: -{
-  "description": "Optional. Expected audience size.",
-  "type": "string"
-}

removedInput schema / properties / budget

Removed value: -{
-  "description": "Optional. Budget for the event, any currency.",
-  "type": "string"
-}

changedInput schema / properties / event_date / description

Previous value: -"Event date, for example \"17 February 2027\"."New value: +"Event date, for example \"17 February 2027\". If the date is not yet fixed, give the intended month or timeframe."

removedInput schema / properties / event_format

Removed value: -{
-  "description": "Event format.",
-  "enum": [
-    "in-person",
-    "virtual",
-    "pre-recorded"
-  ],
-  "type": "string"
-}

removedInput schema / properties / event_type

Removed value: -{
-  "description": "Optional. Type of event.",
-  "enum": [
-    "internal",
-    "external",
-    "industry-conference",
-    "board",
-    "other"
-  ],
-  "type": "string"
-}

removedInput schema / properties / how_heard

Removed value: -{
-  "description": "Optional. How the enquirer heard about Thomas.",
-  "items": {
-    "enum": [
-      "google",
-      "linkedin",
-      "ai",
-      "other"
-    ],
-    "type": "string"
-  },
-  "type": "array"
-}

removedInput schema / properties / location

Removed value: -{
-  "description": "Event location, for example \"Oslo, Norway\".",
-  "type": "string"
-}

changedInput schema / properties / message / description

Previous value: -"Optional. Anything else you would like to share."New value: +"A short free-text description of the event. Fold everything relevant into this one field in natural language: event location, format (in person, virtual, or pre-recorded), the topic or theme you would like Thomas to speak about, expected audience size, the organisation and your role, and budget if you have one. Thomas reads this and replies with availability and a tailored proposal."

removedInput schema / properties / organisation

Removed value: -{
-  "description": "Optional. Organisation name.",
-  "type": "string"
-}

removedInput schema / properties / title

Removed value: -{
-  "description": "Optional. Your job title.",
-  "type": "string"
-}

removedInput schema / properties / topic

Removed value: -{
-  "description": "What you would like Thomas to speak about.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "name",
-  "email",
-  "event_format",
-  "event_date",
-  "location",
-  "topic"
-]New value: +[
+  "name",
+  "email",
+  "event_date",
+  "message"
+]

5 tool updatesJul 10, 2026
- First observedget_availability_guidance
- First observedget_booking_info
- First observedget_speaker_profile
- First observedget_speaking_topics
- First observedsubmit_speaking_inquiry

Related MCP Connectors

AI Rollout Framework A
com.airolloutframework
90-day AI adoption framework for managers: overview, pricing, FAQ and an AI readiness assessment.
Documentation Access AI & Machine Learning
91
In-Context — AI-Native Portfolio A
me.in-context
An interactive portfolio built for AI conversations. Browse work, services, and book calls.
Developer Tools Marketing Content Management Systems
32
LiftliOAuth
io.github.liftli-ai
Strategist, ghostwriter, scheduler and analyst in one, inside your AI. LinkedIn, X, Substack.
Social Media Marketing
1
Agrus.ai — Enterprise AI Agency A
io.github.phwizard
AI consulting agency for regulated industries. Scope a PoC, query compliance, request a proposal.
AI & Machine Learning Legal & Compliance
72

Related MCP Servers

EasyAiFlows Automation
AI & Machine Learning App Automation
Ronnie-Nutrition
A
license
A
quality
D
maintenance
Assess your business's AI automation readiness across 20 industries. Get a personalized score, specific recommendations, and time/revenue impact estimates
Updated 6 months ago (2026-04-06 02:44 UTC)
2
13 npm
1
MIT
Sessionize MCP Server
Search Research & Data
aws-user-group-toolkit
F
license
Not graded
quality
D
maintenance
Enables AI agents to search for speakers and talks by date using the Sessionize API.
Updated 8 months ago (2026-02-08 18:42 UTC)
-
ai-business-system-advisor-mcp
App Automation AI & Machine Learning
tenkai2018
A
license
A
quality
D
maintenance
Helps founders and teams review business workflows, identify AI opportunities, assess trust/control risks, and recommend a safe first AI-human workflow.
Updated 4 months ago (2026-05-31 06:28 UTC)
9
70 npm
Cryptographic Autonomy 1.0 (Combined Work Exception)
Mentoring Inquiry Builder
Education & Learning Tools
marian-kamenistak
A
license
Not graded
quality
B
maintenance
Enables AI assistants to guide users through hiring an engineering-leadership mentor, from getting options and matching focus to designing a program and booking an intro call. It computes prices server-side and sends a formal itemized offer after explicit price agreement.
Updated a day ago (2026-10-09 14:26 UTC)
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?