TESSA Marketing & Technology
Server Details
TESSA's AI interface: services, case studies, AI-readiness audits, professional services directory.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 10 of 10 tools scored. Lowest: 2.8/5.
Each tool has a clearly distinct purpose: AI readiness assessment, listing claims, directory search, case studies, firm profiles, service catalog, WCAG audit, introductions, quotes, and strategy sessions. There is no overlap or ambiguity between tool functions.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., assess_ai_readiness, get_services, request_quote). The naming convention is uniform and predictable across the entire set.
With 10 tools, the coverage is well-scoped for a marketing and technology directory/server. Each tool serves a distinct function relevant to the domain, and the count is neither too sparse nor too bloated.
The tool set covers the primary workflows: discovery (search, profiles, services), assessment (AI readiness), and engagement (introductions, quotes, sessions). Minor gaps exist (e.g., no tool for updating firm profiles or listing all firms without search), but these are not critical for the intended use case.
Available Tools
10 toolsassess_ai_readinessAInspect
Given a website URL, returns a 0-100 AI Agent Readiness score with category breakdowns (structured data, metadata quality, agent discoverability, AI-bot friendliness) and concrete recommendations. Pure deterministic check, fast, no LLM call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deterministic, fast, no LLM call; but no annotations, and missing details like data sent, privacy, error handling, or accessibility requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences; no wasted words; all information adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and output but omits error handling and output format details; almost complete given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, description only says 'Given a website URL'; lacks format constraints (protocol, length) or error conditions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool assesses AI readiness of a website URL, returns a 0-100 score with category breakdowns and recommendations, distinguishes from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for quick deterministic check (fast, no LLM call) but lacks explicit when-to-use/not-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim_listingAInspect
Record a firm's intent to claim its directory listing.
Pre-OAuth this does NOT automatically grant control of the listing. TESSA logs the claim and a representative reaches out via email within one business day to verify the claimant and switch the listing's verification status to 'claimed'. The full self-service OAuth-2.1 claim flow lands in a follow-up plan.
| Name | Required | Description | Default |
|---|---|---|---|
| firm_slug | Yes | ||
| claim_email | Yes | ||
| claimant_name | No | ||
| claimant_role | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals key behavioral traits: the action logs a claim, does not grant control immediately, involves human verification within one business day, and mentions future OAuth flow. This sets accurate expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose and provide necessary behavioral context. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple parameters and no output schema, the description covers the essential workflow and limitations. It could be more complete by explaining how to obtain firm_slug or formatting claim_email, but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain any of the four parameters (firm_slug, claim_email, claimant_name, claimant_role). No meaning is added beyond the schema, leaving the agent without guidance on how to populate these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a firm's intent to claim its directory listing, using specific verbs and resource. It distinguishes itself from sibling tools like get_firm_profile or request_introduction by focusing on the claiming process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage context (e.g., pre-OAuth limitations) but does not explicitly guide when to use this tool versus alternatives or provide when-not-to-use scenarios. The mention of the full OAuth flow being in the future gives some context but lacks explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_professional_services_firmCInspect
Search the TESSA Professional Services Directory.
industry: segment slug ('marketing' | 'compliance')
or free-text keyword
region: city or state name (case-insensitive contains)
capability: keyword to match against firm descriptions and service names
limit: max results
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| region | No | ||
| industry | No | ||
| capability | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It does not disclose read-only nature, authentication needs, rate limits, pagination, or any side effects. The description only lists parameters 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but uses a bullet-like format that is not grammatically complete. It front-loads the purpose but the parameter listing is terse, fitting in a small space yet not fully structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema description coverage and no output schema, the description leaves significant gaps: no information on return structure, pagination, sorting behavior, or error handling. The agent cannot fully understand what the tool returns or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds basic meaning to each parameter: industry as segment slug or free-text, region as city/state case-insensitive contains, capability as keyword match, and limit as max results. However, it lacks detail on format of industry slug (only two examples) and does not explain other parameter behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the TESSA Professional Services Directory, distinguishing it from siblings like get_firm_profile (retrieves specific firm) and request_* tools (actions). The parameter list gives additional context on search options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or when not to. No comparison to sibling tools like get_firm_profile or get_services, leaving the agent to infer usage independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_studiesAInspect
Returns TESSA's portfolio of project results.
Optional filters:
industry: industry name keyword (case-insensitive contains)
service_slug: filter to studies that used a given service
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | ||
| service_slug | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It fails to disclose behavioral traits beyond the basic retrieval action, such as read-only nature, authentication needs, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the main purpose, and presents optional filters in a clean list. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two optional parameters and no output schema, the description covers the core function and filter behavior. It lacks details on return format (e.g., list of objects), but overall is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates fully by explaining both optional filters: industry is a case-insensitive contains keyword, service_slug filters by service. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns TESSA's portfolio of project results, using a specific verb and resource. The tool name and description distinguish it from siblings like get_services or get_firm_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance, and no alternatives mentioned. The description implies usage for retrieving case studies but lacks explicit context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_firm_profileBInspect
Returns the full dossier for a single firm in the directory: description, headquarters, founded year, employee band, services, locations, and directory meta (publisher, claim URL, takedown URL).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists output fields and does not disclose behavioral traits such as error handling (e.g., 404 if slug not found), authentication needs, rate limits, or idempotency. The agent is left without important behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a concise list of fields. It is front-loaded and contains no unnecessary words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description partially covers return values but misses parameter semantics and behavioral context. The lack of guidance on when to use versus siblings reduces completeness. A more complete description would include parameter details and contrast with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the 'slug' parameter. It fails to explain what a slug is (e.g., unique identifier, URL-friendly name) or how to obtain it. Without this guidance, the agent may misuse the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'the full dossier for a single firm' and enumerates the fields (description, headquarters, etc.), using a specific verb and resource. It distinguishes from sibling 'find_professional_services_firm' which is for searching/finding firms, whereas this retrieves a specific firm's detailed profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a slug, but does not explicitly state when to use this tool versus siblings like find_professional_services_firm. No alternatives or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_servicesAInspect
Returns TESSA's full service catalog (SEO, paid media, web/app development,
AI agent readiness, accessibility, and more). Each service includes its live
per-service A2A card URL (agent_card) and JSON-RPC endpoint (a2a_endpoint),
so you can discover a service here and then talk to its dedicated A2A agent.
Optional filters:
category_slug: marketing | web-development | ai-experiences
service_slug: filter to one specific service
| Name | Required | Description | Default |
|---|---|---|---|
| service_slug | No | ||
| category_slug | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output includes A2A card URL and endpoint, but does not mention rate limits, authentication, pagination, or behavior with empty results. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and includes details about filters. It is fairly concise, though the filter list could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains exactly what each service entry includes (agent_card and a2a_endpoint) and the filter options. For a listing tool, this is complete and sufficient for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no descriptions in the input schema. The description adds values for category_slug and explains service_slug filters to one service, but does not list possible service_slugs, so only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns TESSA's full service catalog with specific service types listed. It distinguishes from sibling action-oriented tools by being a discovery/list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering services before talking to their agents, but does not explicitly state when not to use this tool or provide alternatives. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wcag_auditAInspect
Returns the structured offering for TESSA's WCAG 2.2 AA Accessibility Audit: scope, deliverables, timeline, pricing bands (hourly + engagement range), paired service-type slugs, and the URL of TESSA's profile in the TESSA Compliance Registry. Use this when a buyer agent needs TESSA's accessibility audit offering in structured form.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as idempotency, side effects, or authentication needs. The description only states what is returned, not how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. It front-loads the primary purpose and immediately provides actionable context for when to use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the tool's purpose and return content well. However, it omits any mention of prerequisites (e.g., need to be in a certain context) or whether the data is static, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add parameter-level meaning. However, it provides value by detailing the return fields (scope, deliverables, timeline, etc.) beyond what the empty schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a structured offering for a specific audit, using specific verb 'Returns' and naming the exact resource 'TESSA's WCAG 2.2 AA Accessibility Audit'. It avoids ambiguity and distinguishes from siblings like get_firm_profile or get_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a usage context: 'Use this when a buyer agent needs TESSA's accessibility audit offering in structured form.' While it does not list exclusions or alternatives, the context is clear and helps an agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_introductionAInspect
Request an informational introduction — to TESSA itself, or to any directory firm if you pass target_firm_slug. TESSA logs the lead and either notifies sales@tessa.tech + kevincallen@tessa.tech (TESSA leads) or forwards a warm intro email to the firm with TESSA Cc'd (directory leads). No calendar booking — use request_strategy_session to book a meeting with TESSA.
| Name | Required | Description | Default |
|---|---|---|---|
| prospect_org | No | ||
| project_brief | No | ||
| prospect_name | No | ||
| prospect_email | Yes | ||
| requested_window | No | ||
| target_firm_slug | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it logs the lead, notifies specific emails for TESSA leads, or forwards a warm intro email for directory leads with TESSA Cc'd. It also clarifies that no calendar booking occurs, which is important side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences long, with no redundant information. It front-loads the purpose, then explains behavior for two cases, and ends with a clear exclusion. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the main aspects (purpose, usage, behavior) but leaves gaps for several optional parameters (e.g., prospect_org, project_brief, requested_window). The tool's complexity is moderate with 6 parameters, and the description could be more complete by explaining these parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage, so the description must compensate. It explains the purpose of target_firm_slug (to direct the introduction to a directory firm) but does not elaborate on prospect_org, project_brief, prospect_name, or requested_window. The required prospect_email is not described beyond being the email. Partial value added, but several parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'request' and the resource 'introduction', and distinguishes two scenarios: to TESSA itself or to a directory firm via target_firm_slug. It also differentiates from the sibling tool request_strategy_session by explicitly stating 'No calendar booking'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for informational introductions) and when not to (for booking meetings, use request_strategy_session). It also explains the two different outcomes depending on whether target_firm_slug is provided, giving clear 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.
request_quoteBInspect
Request a quote from a directory firm. Lighter-weight than request_introduction — explicitly framed as a budget+scope inquiry.
firm_slug: directory slug for the target firm
prospect_email: caller's email for the firm's reply
scope_summary: one-paragraph description of the work
budget_band: 'under_5k' | '5k_25k' | '25k_100k' | '100k_plus' |
'open' — or any free-text dollar figure
| Name | Required | Description | Default |
|---|---|---|---|
| firm_slug | Yes | ||
| budget_band | No | ||
| prospect_org | No | ||
| prospect_name | No | ||
| scope_summary | Yes | ||
| prospect_email | Yes | ||
| requested_window | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states the tool is for requesting a quote and is lighter-weight, but does not explain side effects (e.g., triggers an email), required permissions, or what happens after submission. The minimal description fails to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loads the purpose and key contrast. However, the parameter list is incomplete and not aligned with the schema, which detracts from its usefulness. It could be restructured to mention all parameters or note that only a subset is described.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It covers only 4 parameters and provides no information about return values, error states, or post-request behavior. The agent lacks essential context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It describes only 4 out of 7 parameters (firm_slug, prospect_email, scope_summary, budget_band) with helpful details like enum values for budget_band. However, it completely omits prospect_org, prospect_name, and requested_window, leaving the agent uninformed about these optional inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request a quote from a directory firm.' It explicitly distinguishes itself from the sibling tool 'request_introduction' by noting it is lighter-weight and framed as a budget/scope inquiry. This meets the highest standard of clarity and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it is lighter-weight than request_introduction and for budget/scope inquiries. This helps the agent decide between the two. However, it does not mention when to avoid this tool or discuss alternatives among other siblings, though the direct comparison is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_strategy_sessionAInspect
Book a 30-minute strategy session with TESSA on Kevin Callen's calendar. Finds an open slot in the requested window (or the next 5 business days), creates a Google Calendar event with a Google Meet link, and emails the prospect the invite. If no slot is available, captures the lead and Kevin follows up manually. TESSA-only tool — directory firms use request_introduction instead.
requested_window accepts ISO 8601 ranges ('2026-04-30T13:00/2026-04-30T17:00'),
single dates ('2026-04-30'), or English ('tomorrow', 'next week').
| Name | Required | Description | Default |
|---|---|---|---|
| prospect_org | No | ||
| project_brief | No | ||
| prospect_name | No | ||
| prospect_email | Yes | ||
| requested_window | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses the booking flow: it finds a slot, creates a calendar event with Meet link, sends an email, and handles unavailability. However, it omits potential side effects or authentication requirements, though these are minor for this use case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose, detailed workflow, usage guidance, and a parameter example. It is slightly verbose but each sentence adds value; could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description covers the core workflow and one parameter format, but lacks explanations for three parameters and the return value, making it incomplete for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only details 'requested_window' with accepted formats, but fails to explain prospect_org, project_brief, or prospect_name, leaving significant gaps in understanding required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool books a 30-minute strategy session with TESSA on Kevin Callen's calendar, specifies the process (finds slot, creates event with Meet link, emails invite), and distinguishes from sibling tool request_introduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'TESSA-only tool — directory firms use request_introduction instead,' providing clear when-to-use and alternative guidance. Also describes fallback manual follow-up when no slot is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!