F
licenseNot graded
qualityD
maintenanceProvides structured tool access to Mario's portfolio data including skills, projects, experience, and services via 7 MCP tools.
-
Thomas Anglero Speaker MCP
by com.anglero
Server Details
Thomas Anglero speaker MCP: bio, keynote topics, booking info, and speaking-inquiry submission.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolsget_availability_guidanceGet availability guidanceARead-onlyInspect
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 informationARead-onlyInspect
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 profileARead-onlyInspect
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 topicsARead-onlyInspect
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 organisation, 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 | Default |
|---|---|---|---|
| name | Yes | Full name of the person making the inquiry. | |
| Yes | Contact email address. | ||
| phone | Yes | Contact phone number, including country code if the event is outside Norway. | |
| company | Yes | The company or organisation 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.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this action writes into the same pipeline as the website form, records the inquiry, and sends confirmation and notification emails. It also notes that Thomas replies personally within two business days, setting response expectations. The anti-spam field behavior ('Leave blank') is described. These details go beyond the minimal readOnlyHint false annotation, which only indicates it is not read-only. No contradictions found.
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?
Three sentences, each earning its place: purpose, parameter requirements plus guidance, and behavioral outcome. The core action is front-loaded. It avoids redundancy with the schema by not repeating every field description, instead providing high-level guidance. Efficient and well-organized.
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?
For a form-submission tool with no output schema, the description covers the essential context: required fields, how to format the message, side effects, and expected response time. It does not specify what the function returns (e.g., success confirmation or ID), but given that it is a fire-and-record operation with email notifications, this omission is minor. The completeness is adequate for an agent to call it 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?
Schema coverage is 100%, so the baseline is 3. The description adds significant value for the message parameter by enumerating precisely what should be folded into it (topic, location, format, audience size, role, budget) in natural language. It also clarifies that 'company' means organization and that phone should include country code if outside Norway, though some of this is in the schema. Overall, the description enhances comprehension 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 opens with a specific verb and resource: 'Send a speaking inquiry to Thomas Anglero.' It clearly differentiates from the sibling get_* tools (all read-only) by describing a write operation that feeds into the website pipeline. The purpose is unambiguous and does not rely on inference.
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 implicitly tells the agent this is the tool to initiate a speaking request, contrasting with the sibling tools that retrieve availability, booking info, profile, or topics. It does not explicitly mention alternatives or when-not-to-use, but the behavioral details (requires six fields, folds all details into message) make the intended usage obvious. A slight boost is lost for not naming a specific alternative scenario, but the context is clear.
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. Dates show when Glama detected each change.
1 tool update
- Changed
submit_speaking_inquiry4 fields changed- added
Input schema / properties / companyAdded value: +{ + "description": "The company or organisation the inquiry is on behalf of.", + "type": "string" +} - changed
Input schema / properties / message / descriptionPrevious 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." - added
Input schema / properties / phoneAdded value: +{ + "description": "Contact phone number, including country code if the event is outside Norway.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "name", - "email", - "event_date", - "message" -]New value: +[ + "name", + "email", + "phone", + "company", + "event_date", + "message" +]
1 tool update
- Changed
submit_speaking_inquiry12 fields changed- removed
Input schema / properties / audience_sizeRemoved value: -{ - "description": "Optional. Expected audience size.", - "type": "string" -} - removed
Input schema / properties / budgetRemoved value: -{ - "description": "Optional. Budget for the event, any currency.", - "type": "string" -} - changed
Input schema / properties / event_date / descriptionPrevious 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." - removed
Input schema / properties / event_formatRemoved value: -{ - "description": "Event format.", - "enum": [ - "in-person", - "virtual", - "pre-recorded" - ], - "type": "string" -} - removed
Input schema / properties / event_typeRemoved value: -{ - "description": "Optional. Type of event.", - "enum": [ - "internal", - "external", - "industry-conference", - "board", - "other" - ], - "type": "string" -} - removed
Input schema / properties / how_heardRemoved value: -{ - "description": "Optional. How the enquirer heard about Thomas.", - "items": { - "enum": [ - "google", - "linkedin", - "ai", - "other" - ], - "type": "string" - }, - "type": "array" -} - removed
Input schema / properties / locationRemoved value: -{ - "description": "Event location, for example \"Oslo, Norway\".", - "type": "string" -} - changed
Input schema / properties / message / descriptionPrevious 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." - removed
Input schema / properties / organisationRemoved value: -{ - "description": "Optional. Organisation name.", - "type": "string" -} - removed
Input schema / properties / titleRemoved value: -{ - "description": "Optional. Your job title.", - "type": "string" -} - removed
Input schema / properties / topicRemoved value: -{ - "description": "What you would like Thomas to speak about.", - "type": "string" -} - changed
Input schema / requiredPrevious value: -[ - "name", - "email", - "event_format", - "event_date", - "location", - "topic" -]New value: +[ + "name", + "email", + "event_date", + "message" +]
5 tool updates
- First observed
get_availability_guidance - First observed
get_booking_info - First observed
get_speaker_profile - First observed
get_speaking_topics - First observed
submit_speaking_inquiry
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Public portfolio MCP for resume, services, availability, project evidence, and introductions.
Blog posts, work experience, projects and contact details for Markus Tenghamn, as MCP tools.
Read-only MCP server for Frank Poncelet: profile, career, projects, speaking, expertise, persona.
Labangram portfolio, services, pricing, and inquiry MCP endpoints.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceRemote MCP server exposing tools to explore Allen Hoem's professional record, including patents, media, and contact requests.MIT
- FlicenseAqualityBmaintenanceMCP server that exposes a resume as callable tools and resources, enabling AI agents to query experience, skills, projects, and contact information via natural language.3-
- AlicenseAqualityBmaintenanceThe Ritwik Joshi Personal MCP Server is a standardized Model Context Protocol (MCP) data source designed to give AI agents direct, authoritative tool access to his professional profile. It features eight tools that enable AI assistants to fetch real-time information regarding his speaker profile, keynotes, TEDx talks, blog articles, and booking details without relying on outdated data.329MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.4/5.0
Disambiguation5/5
Each tool targets a distinct concern: profile, topics, availability, booking process, and inquiry submission. There is no overlap; an agent can easily select the right tool based on the user's intent.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: 'get_' for informational queries and 'submit_' for the action. The naming is uniform and predictable, making tool selection straightforward.
Tool Count5/5
With exactly 5 tools, the set is well-scoped for a speaker booking server. Each tool serves a clear purpose and there are no redundant or missing essential functions.
Completeness5/5
The tool surface covers the entire lifecycle of a speaking inquiry: profile discovery, topic details, availability guidance, booking procedures, and the actual submission. While some specifics (rates, exact dates) are only provided on inquiry, that is consistent with the server's stated design and leaves no dead ends.