Thomas Anglero Speaker MCP

Submit a speaking inquiry

submit_speaking_inquiry

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 promptly.

Input 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 "February 17, 2027". If the date is not yet fixed, give the intended month or timeframe.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / event_date / description

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

Changed1 schema field changedSep 21, 2026

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."

Changed4 schema fields changedAug 25, 2026

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"
+]

Changed12 schema fields changedJul 13, 2026

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"
+]

First observedJul 10, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, so the description carries the disclosure burden and does so well: it says the inquiry is written into the same pipeline as the website form, that confirmation and notification emails are sent, and it flags the website field as an anti-spam trap. That is meaningful behavioral context 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.

Conciseness4/5

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

Three sentences, front-loaded with purpose and requirements, with no filler. It loses a point because the long enumerations of foldable details and required fields substantially duplicate the schema's field descriptions.

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?

There is no output schema, and the description compensates by explaining what happens after submission (recording, emails, prompt reply). For a 7-parameter mutation tool with full schema coverage, an agent has enough to call it correctly; only the lack of routing guidance against the advisory sibling is missing.

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 description coverage is 100%, so every parameter is already documented, including the fold-everything-into-message guidance. The description restates the required field list and the message content list without adding format or validation detail beyond the schema, so the baseline 3 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?

States a specific verb (send) and resource (speaking inquiry) with a named recipient, Thomas Anglero. It implicitly separates itself from the sibling submit_advisory_inquiry, but never names an alternative explicitly, so it just misses the 5 bar.

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 instructs how to fill the form but never states when to choose this over submit_advisory_inquiry or when to consult get_speaker_profile/get_speaking_topics first. Usage is implied by the purpose rather than guided.

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

All Thomas Anglero Speaker MCP tools Inspect

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?