TESSA Marketing & Technology
Server Details
TESSA's AI interface: services, case studies, AI-readiness audits, professional services directory.
- Status
- Healthy
- 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.6/5 across 10 of 10 tools scored. Lowest: 2.8/5.
Each tool targets a distinct action: assessing readiness, claiming listings, searching directory, retrieving profiles/services/case studies/audit info, and making different types of requests. No overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., claim_listing, get_firm_profile, request_strategy_session). No mixing of conventions.
10 tools is well within the ideal 3-15 range and covers the domain thoroughly without being overwhelming or sparse.
Covers core workflows: directory search/retrieval, service catalog, audit info, and various request types. Minor gaps exist (e.g., no tool to update directory listings), but the set is largely complete for its purpose.
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). 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?
No annotations exist, so description must convey behavioral traits. It mentions returns catalog but omits side effects, authentication needs, rate limits, or data volume. Read-only nature is implied but not explicit.
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?
Description is concise, front-loading the main purpose, and uses parentheses to list examples. Every sentence adds value, though a slightly more structured format could improve clarity.
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?
No output schema exists, so description should clarify return format. It states 'full service catalog' but not structure (e.g., list of objects). With no annotations and moderate complexity, completeness is adequate but not thorough.
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%, but the description explains the two optional filters, listing valid category_slug examples and stating service_slug filters to one service. This adds essential meaning 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?
Description clearly states verb 'Returns' and resource 'TESSA's full service catalog', listing example services. Sibling tools like assess_ai_readiness or claim_listing serve different purposes, so this tool is well-distinguished.
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?
Description implies use when accessing the full service catalog or filtering by category/service, but does not explicitly state when to use this tool over siblings or provide exclusion criteria. Lacks direct guidance.
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!