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 personally, typically within two business days.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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

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.

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?