meetergo MCP server

Official

by meetergo

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.25
Disambiguation3/5
Most tools follow a clear verb+resource pattern that keeps them distinct, but create_qualification_form substantially overlaps with create_routing_form since both create routing forms. The appointment tool cluster (book, reschedule, cancel, list, get, get_todays) is individually clear but numerous, and send_routing_form vs send_quick_email could cause momentary misselection.
Naming Consistency5/5
All 57 tools use snake_case with a consistent verb_noun structure: list_* for collections, get_* for single resources, and create_*/update_*/delete_* for CRUD operations. Exceptions like bulk_create_contacts, run_test_drive, and verify_widget_install still follow the verb-first pattern. This is exemplary consistency at scale.
Tool Count2/5
At 57 tools, this vastly exceeds the typical well-scoped range and exposes nearly the entire meetergo product surface. Each tool appears to serve a real function, but the sheer number creates a heavy navigation burden and makes it difficult for an agent to maintain a working model of the full set.
Completeness4/5
The major domains are thoroughly covered: appointments, meeting types, contacts, routing forms, webhooks, and Mira settings all have near-full CRUD/lifecycle support. Minor gaps exist — data fields have no update/delete, calendar connections are list-only, and knowledge ingestion is limited to crawling or single Q&A answers — but these are workable without agent failure.
Average 4.2/5 across 57 of 57 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context beyond those annotations: pages are 0-indexed, every item carries a confirmed/cancelled status, and cancelled items are excluded from upcoming appointments. This helps an agent interpret pagination and status semantics correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences, each carrying meaningful information: the core purpose, the status behavior, and the pagination indexing. There is no redundancy or filler, and the most important fact (appointmentId for changes) appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core list behavior and pagination, but with nine optional parameters and low schema coverage, it leaves several parameters uninterpreted. The presence of an output schema and annotations lessens the burden, but the lack of guidance about filter semantics and when to choose this tool over siblings keeps it from being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44%, so the description should compensate by explaining the less-documented parameters. It does not: meetingTypeId, sortBy, sortDirection, and pageSize are not mentioned at all, and status is only touched on in a general semantic sense. The only useful parameter-level additions are the 0-indexed page note and the status filtering implication, which is insufficient for nine parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: returning appointments with pagination and filtering, and highlights the appointmentId as the needed identifier for later changes. It does not explicitly distinguish itself from sibling list tools like get_todays_appointments, so it misses the final point of differentiation, but the verb+resource+scope are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as get_todays_appointments or get_appointment. The note about cancelled items not being upcoming appointments implies a filtering use case, but it never names alternatives or exclusion conditions, leaving the agent to infer when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish the safety profile (write, non-idempotent, non-destructive, open world). The description adds genuinely useful behavioral context beyond the schema: the meeting type goes live and publicly bookable immediately upon creation, and the URL slug is auto-generated from the name yet remains editable. No contradiction with annotations.
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, roughly 40 words, with the core purpose front-loaded and each sentence earning its place. Slight redundancy with the tool name ('Create a new meeting type') is offset by the added ownership and side-effect details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with an output schema and annotations covering the safety profile, the description captures the non-obvious facts an agent must know: immediate public visibility and slug derivation/editability. Minor gaps exist (e.g., no guidance on duplicate name behavior or prerequisites), but nothing critical is missing for a correct call.
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 69%, and the schema already documents most structured parameters well (duration range, 'local' channel semantics, buffer limits). The description adds one meaningful parameter relationship — the slug derives from the name — but does not compensate for the four undocumented boolean flags (enableRedirect, showAvailableSlots, etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Create a new meeting type') and adds ownership scope ('owned by the authenticated user') plus the key consequence ('becomes a real, publicly bookable page immediately'). This is clear and distinguishes create from update/delete/list siblings, though it does not explicitly name alternatives like create_one_time_booking_link to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. Given a large sibling list containing overlapping booking concepts (create_one_time_booking_link, import_booking_page, update_meeting_type), the absence of any when-to-use/when-not-to-use statement leaves the agent to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds important behavioral context: PATCH semantics ('Only the fields you send change') and the color gating condition ('Colours need useCustomColors set, or they are ignored'). This meaningfully reduces surprise for an update tool marked destructiveHint. It does not enumerate every mutation detail, but the schema covers specifics like null headerImage removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the primary purpose front-loaded and the two most important behavioral caveats stated immediately after. There is no filler, hedging, or repetition of per-field schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential semantics for safe use (partial update and color dependency) are present, and annotations plus an output schema cover safety and return-shape expectations. However, the description omits the tool's non-branding capabilities and provides no routing guidance among sibling page tools. For an 8-parameter mutation tool, this leaves a moderate completeness gap.
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?
The schema already describes 6 of 8 parameters, including hex format and online profile subfields, so the description is not required to repeat them. The added partial-update rule is valuable across all parameters, but the color condition largely duplicates the useCustomColors schema description. The description does not compensate for the undocumented showAllMeetingTypes parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and target ('Change branding on the personal booking page'), making the operation clear and separating it from get_personal_page. It is slightly narrow, since the schema also supports meetingTypeOrder and showAllMeetingTypes, which are not strictly 'branding'. That scope mismatch prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement about when to choose this tool over alternatives (e.g., get_personal_page to read or import_booking_page to replace the page) is present. The only usage signal is the implied intent to modify the booking page, with no exclusions, prerequisites, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds some context about document source types and source keys, but it does not disclose behaviors like pagination, authentication requirements, or whether the list is exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact fragment with no filler words. It front-loads the resource and scope, and every clause adds meaningful detail about what the tool returns.
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?
With zero parameters, an output schema provided, and annotations covering the safety profile, the description is sufficient for an agent to call the tool correctly. The mention of source keys and document categories adequately frames the result set without needing to explain return values, since the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The schema coverage is trivially 100%, and no parameter semantics are needed since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (documents in the company's Mira knowledge base) and the specific categories returned (crawled pages, uploaded files, synced sources). It is a clear list operation, though it does not explicitly differentiate itself from semantically similar siblings like search_company_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. An agent cannot tell from the description whether to choose this over search_company_knowledge or whether there are any exclusions, filters, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral constraint—six webhooks per company maximum—and notes that the API enforces this with an error. Annotations already signal this is not read-only, not idempotent, and not destructive, so the added quota context is helpful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary purpose front-loaded and the quota constraint in the second sentence. There is no padding or redundancy, and every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward create operation with an output schema present, the description covers the core purpose and a key limitation. It does not explain when to use this versus update_webhook, but the schema and annotations handle most operational details.
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?
The schema already documents endpoint and description, and eventTypes is covered by its enum values. The description's phrase 'receive events' broadly aligns with eventTypes but does not add new parameter-level meaning beyond what the schema provides.
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 uses the specific verb 'Register' with the resource 'an HTTPS endpoint to receive events,' making it clear this tool creates a webhook. This distinguishes it from sibling tools like list_webhooks, update_webhook, and delete_webhook without needing to open the schema.
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 intended use case is implied: use this tool when you need an HTTPS endpoint to receive events. However, it does not explicitly state when to prefer this over alternatives or mention conditions like updating an existing webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the basic safety profile is covered. The description adds a valuable behavioral detail: unspecified fields keep their current values, which prevents the agent from assuming omitted fields are reset. This is useful context beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action is front-loaded, and the critical partial-update clarification follows immediately. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the main invocation nuance—partial updates—and the required meetingTypeId is documented in the schema. It lacks explicit sibling differentiation and does not discuss effects on a live booking page, but destructiveHint covers the safety concern.
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 60%, covering most meaningful parameters like name, slug, color, channel, duration, redirect, and buffers. The description adds the important partial-update rule for all optional parameters, but it does not explain the remaining undocumented booleans; their names are largely self-explanatory.
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 the specific verb 'Change' and the resource 'meeting type', which clearly distinguishes it from sibling tools like create_meeting_type, delete_meeting_type, and get_meeting_type. An agent can tell what this tool does without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_meeting_type or delete_meeting_type. It explains the partial-update semantics but never states 'use this to modify an existing meeting type' or directs the agent to a sibling tool for creating or deleting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond the annotations by explicitly stating that 'eventTypes replaces the existing list,' which is a non-obvious destructive/overwrite behavior. The annotations already indicate destructiveHint=true, and the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The main action is front-loaded, and the critical replacement behavior is called out in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with annotations covering destructive behavior and an output schema present, the description is largely sufficient. It covers the important fields and the key replace behavior, though it could have explicitly noted that omitted optional fields are left unchanged.
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 0%, so the description carries the burden of explaining parameters. It explains endpoint, description, and eventTypes, and clarifies the replacement semantics for eventTypes. However, it does not mention the required webhookId parameter or its role as the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and names the resource (a webhook) and the mutable attributes (endpoint, description, eventTypes). It clearly conveys this is an update operation, but it does not explicitly differentiate from sibling create_webhook or delete_webhook beyond the verb.
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 intended use is implied: change an existing webhook's settings. However, it does not state when to use this tool versus create_webhook or delete_webhook, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavior beyond annotations: the form is editable, there is a fallback rule routing to a meeting type or callback, and the returned formId is intended for a qualifying web chat profile. These details help an agent anticipate the created artifact and its downstream use, and nothing contradicts the annotations.
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?
Two sentences contain the essential behavior and output context without wordiness. The first sentence is somewhat long but still information-dense and readable, and the second sentence adds useful guidance about the formId's role.
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?
With an output schema present, the description does not need to explain return values in depth, and it covers the main creation behavior plus the web chat profile use case. It omits explicit alternative routing, but the schema and annotations cover most remaining context.
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 coverage is 75%, so the schema already documents most parameter meanings. The description's mention of 'meeting type or callback' mirrors the schema's explanation of meetingTypeId but adds no new parameter-level detail beyond what the input schema provides. Baseline 3 is appropriate.
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 states a specific verb ('Create'), a specific deliverable ('routing form from supplied qualification questions'), and the key behavior ('structured fields the company can edit' plus a fallback rule). This clearly distinguishes it from generic siblings like create_routing_form without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — when you have supplied qualification questions and need a routing form — but it does not explicitly name alternatives such as create_routing_form or explain when one would prefer that generic sibling. Usage context is clear but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations by explaining that qualifiers route on answers and that isFallback provides the default route. It aligns with the annotations, which mark this as a non-read-only, non-idempotent write operation, without needing to restate those cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the primary purpose appears in the first sentence, and the next two sentences add only high-value routing semantics. There is no filler or redundant restatement of the tool name.
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?
The schema is rich, covers most parameters in detail, and an output schema exists, so the description does not need to explain return values. The main gap is the lack of guidance for choosing this tool over related creation tools, but the available structured data makes the description complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents most parameters, but the description adds meaning by tying fields to existing reusable data fields and clarifying isFallback semantics. This is especially valuable because the qualifiers nested object is only loosely described in the schema and lacks formal property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Create a routing form or funnel.' It also adds distinguishing details about fields referencing existing data fields and qualifiers routing on answers, which separates it from generic create tools. It does not explicitly contrast it with sibling create_qualification_form, so it falls just short of a 5.
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?
Usage is implied rather than explicit: the description indicates the tool is for building routing forms/funnels and that fields should reference existing data fields. It does not state when to prefer this over create_qualification_form or provide exclusion criteria, so the agent must infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that it returns the full current configuration and frames it as the basis for a safe update, but it does not disclose additional behavioral traits such as auth requirements or error conditions beyond what the output schema likely covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a front-loaded verb and resource, followed by a compact field list and a one-line purpose. Every part is useful and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only, idempotent tool with an output schema, the description is nearly complete. The only meaningful gap is an explicit pointer to how to obtain meetingTypeId, though the parameter name and the presence of list_meeting_types make the intent recoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for meetingTypeId and the tool description does not address the parameter at all. With 0% schema description coverage, the description should have compensated by explaining where the ID comes from or how it should be formatted, but it leaves the agent to infer from the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the full configuration of one meeting type' and enumerates the fields returned (duration, channel, buffers, booking questions, reminders, host or queue). This makes it clearly distinct from sibling tools like list_meeting_types by emphasizing a single fully-detailed type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear use case: 'The result exposes the current values needed for a safe update,' which signals the agent to call this before modifying a meeting type. It does not explicitly name alternatives or state when not to use it, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about what the returned definition includes, but does not disclose additional behavioral details such as error handling or data source behavior, which is acceptable given the read-only, idempotent nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the key concept ('Full definition of a routing form') and then enumerates the contained elements, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one parameter, a rich output schema, and comprehensive annotations, the description covers the essential content of the response. Minor gaps remain around parameter semantics and explicit alternative routing, but these are not critical for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, formId, with no description, and schema description coverage is 0%. The description only ties formId to 'a routing form' implicitly, giving minimal semantic context. It does not explain what formId should be (e.g., UUID, slug, external ID) or where to find it, so it fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: retrieving the full definition of a routing form, including steps, fields, and qualifier rules. This distinguishes it from siblings like list_routing_forms, which would provide a listing rather than a complete definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full definition of a routing form' implies this is the tool to use when complete routing-form details are needed, in contrast to listing or modifying routing forms. However, it does not explicitly state when not to use it or mention the alternative list_routing_forms by name, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and idempotentHint=false, and the description adds valuable context beyond them: background execution, same-origin restriction, extraction/chunking/embedding pipeline, progress accessibility via status reads, and the idempotent behavior on unchanged sites. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-load the primary action, then efficiently add status and re-crawl/idempotency details. No filler words; every sentence contributes distinct, useful information.
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?
An output schema exists, so return-value details are not needed in the description. The description covers background behavior, scope, re-crawl semantics, and prerequisites, giving an agent enough to invoke the tool correctly. The only minor gap is the unexplicated maxPages parameter, but the schema's min/max constraints partially mitigate that.
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?
The schema documents url and language with descriptions, and the description reinforces the 'same-origin' constraint, but it adds little parameter-specific meaning beyond that. The maxPages parameter is undocumented in both the schema and the description, leaving a 33% coverage gap unaddressed.
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 states a specific action ('Start a background crawl'), an explicit target (a website into the company's Mira knowledge base), and the scope (sitemap and same-origin links). It clearly differentiates this ingestion tool from status, list, search, and other sibling tools.
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 provides practical context such as re-crawling unchanged sites ingesting 0 pages and the entitlement requirement, which helps decide when to call it. However, it does not explicitly contrast with alternative ingestion or search tools, leaving some selection logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a non-obvious behavioral trait: existing contacts are not deduplicated. This goes beyond the annotations, which only indicate that the operation is not read-only and not idempotent. The warning adds practical value for agents deciding whether to call this tool repeatedly or to search first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action, states the key requirement, and adds a valuable warning. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential operational facts: what it creates, what is required, and the deduplication behavior. It is aided by the output schema and annotations, so it does not need to explain return values or safety semantics. A slightly fuller description of optional field relationships would make it complete, but it is not a significant gap.
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?
The schema description coverage is low (29%), but the description adds the important constraint that email or phoneNumber is required, which is not reflected in the schema's required array. Other parameters like firstName, lastName, and accountOwnerId are not explained in the description, though their names are reasonably self-explanatory. The description partially compensates for the schema gaps but not completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a CRM contact.' It clearly identifies the operation and the domain object, distinguishing it from read, update, delete, and bulk-creation operations in the sibling list. However, it does not explicitly contrast itself with bulk_create_contacts, so the distinction is implicit rather than spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating that either email or phoneNumber is required, and by warning that existing contacts are not deduplicated. This helps an agent know what to provide and what to expect. It does not explicitly name alternatives like bulk_create_contacts or update_contact, but the guidance it gives is actionable and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, non-idempotent write operation, and the description's 'Create' is consistent. The description adds useful scope: the field is reusable and company-wide, and options are conditionally required. It does not disclose side effects like permission requirements or impact on existing forms, but annotations lower the burden here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the core action and scope front-loaded and the critical validation rule in the second sentence. No filler or redundancy.
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?
The description covers the tool's main purpose, scope, and a critical fieldType-options constraint. Since an output schema exists, return-value details are not needed. The only real gap is that the choice-versus-text distinction could be more explicit against the 19 fieldType enum values, but the schema's options property partially fills this.
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 67%, so the description should add some value beyond the schema. It does exactly that by explaining the key relationship: choice fields need options while text fields do not. This helps avoid invalid option handling for the many fieldType enum values, though it does not enumerate exactly which types count as choice fields.
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?
States a specific verb and resource: 'Create a reusable form field, company-wide.' This clearly distinguishes the tool from siblings like create_contact or create_webhook, and the added nuance about choice versus text fields gives useful identity. The title is also expanded with meaningful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when a reusable, company-wide form field is needed. However, it does not explicitly name alternative tools or exclusion criteria, such as when a non-reusable or form-specific field would be more appropriate. The guidance is present but only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses exactly what happens: deletion is permanent, past appointments are retained, and the contact record plus form answers are removed. This gives the agent clear expectations about side effects and data preservation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary action front-loaded. Every clause adds meaningful information: permanence, retention of appointments, and removal of contact record and form answers. There is no filler.
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 single-parameter destructive action with an output schema and destructiveHint annotation, the description fully covers what is deleted, what persists, and the permanent nature of the operation. No critical context is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain contactId, but it never explicitly references the parameter. The agent must infer from the property name and the phrase 'a CRM contact' that contactId identifies which contact to delete. This is minimal compensation for a parameter with no schema-level documentation.
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 uses a specific action verb ('delete'), names the exact resource ('CRM contact'), and clarifies the action is permanent. This clearly distinguishes it from sibling delete tools that target other entity types such as knowledge documents, meeting types, routing forms, or webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool instead of alternatives like update_contact, create_contact, or search_contacts. There are no prerequisites, no confirmation steps, and no mention of when deletion is appropriate versus other contact operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive (destructiveHint=true, readOnlyHint=false, idempotentHint=false), so the safety profile is covered. The description goes beyond the annotations by specifying the exact scope of destruction (the document and its chunks) and the immediate consequence for Mira's answering behavior. No contradiction exists between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action ('Remove one document') front-loaded and the consequence as the second sentence. Neither sentence is redundant with the title or schema; both earn their place.
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?
The output schema removes the need to describe return values, and annotations carry the destructive-safety signal. The description supplies the remaining decision-relevant facts: what is deleted (document + chunks) and the immediate effect on Mira. Minor omissions (explicit irreversibility, ID provenance) are implied or made obvious by the sibling list_knowledge_documents, so the description is complete enough for a one-parameter delete tool.
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?
The schema provides only the bare fact that documentId is a required string (0% description coverage), so the description must help. It adds that the ID targets a single knowledge-base document, but it does not explain how to obtain the ID (e.g., from list_kknowledge_documents), its format, or behavior for an invalid/unknown ID. The parameter name is largely self-explanatory and the description's 'one document' clarification provides modest value.
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 names a specific verb ('Remove') and an exact resource — 'one document (and its chunks) from the knowledge base' — so an agent knows precisely what action this triggers. It reads unambiguously as a deletion operation, which sets it apart from retrieval siblings like list_knowledge_documents and search_company_knowledge.
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 second sentence ('Mira stops answering from it immediately') conveys the functional effect, which implies the intended use: permanently cutting a document out of what Mira answers from. However, the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives (e.g., whether any disable or unlink option exists). Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so no safety contradiction exists. The description adds useful behavioral context that results expose contactIds and that the tool is intended for duplicate checks, but it does not describe pagination or result-scope behavior, which would further improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the core action and search criteria, then add the key outcome and intended use case. Every sentence earns its place and there is no redundant filler.
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?
The tool has seven optional parameters, an output schema, and read-only annotations, so the description does not need to explain return structure. It covers the main search intent, duplicate-check use case, and default safety profile; only explicit guidance on how pagination and sorting interact with search 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?
With only 29% schema description coverage, the description adds useful semantic grouping: 'name, email, phone' maps to searchTerm and 'tag' maps to tags. However, it does not address page, limit, sortBy, or sortOrder, leaving those to be inferred from their param names/enums rather than compensated in prose.
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?
States a specific action ('Search'), the resource ('CRM contacts'), and the search dimensions ('name, email, phone or tag'), making it immediately distinct from single-contact retrieval and other knowledge search tools. The added note about contactIds and duplicate checks further clarifies the intended outcome.
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?
Provides clear context by indicating the search supports duplicate checks before contact creation, implying this should be used prior to creating contacts. It does not explicitly name alternatives like get_contact or create_contact, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by explaining that attendeeIds enable guest additions and per-attendee cancellation, and that status indicates whether the booking is active—meaningful semantics beyond a generic read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences, front-loaded with the primary action, followed by the most useful field semantics. Every sentence adds information beyond the schema and none is redundant or promotional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource read tool with an output schema and safety annotations, the description covers the meaningful returned fields and their implications. It lacks only an explicit note on when to prefer this over list_appointments or get_todays_appointments, which is a minor omission given the leading phrase 'one appointment.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'appointmentId' string with 0% schema description coverage. The description does not explain the expected format, origin, or acceptable values of appointmentId; it only implies that the parameter selects the appointment via 'one appointment.' Since the description must compensate for low schema coverage and does not, this is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return full detail for one appointment,' and enumerates the exact fields returned (status, attendees, attendeeIds, hosts, location, notes). This clearly distinguishes it from list-oriented siblings like list_appointments and get_todays_appointments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full detail for one appointment' establishes that this is the tool for fetching a single appointment's comprehensive data rather than a list. It does not explicitly name alternatives or provide exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context by explaining that 'idle' means no crawl has run yet, but it does not detail other possible status values or behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with a concrete example of the idle state. It is front-loaded with the core purpose and contains no filler or redundant information.
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 zero-parameter read-only status tool with an output schema, the description is complete: it states what is being reported, the scope of 'current or last', and the meaning of the idle state. The annotations cover the operational side effects, and the output schema can handle the remaining return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not a burden on the description. The schema fully covers this by defining an empty input, and the description appropriately focuses on the response semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the progress of the current or last knowledge-base website crawl, which is a specific resource and state. It also distinguishes itself from the sibling crawl_company_website, which initiates a crawl, and search_company_knowledge, which queries crawled content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking crawl progress after a crawl has been started, and the 'idle' example signals when no crawl has run. However, it does not explicitly state when to prefer this tool over alternatives or give guidance about polling behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful behavioral context by disclosing the 50-per-page default and offset-based pagination. This goes beyond what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The resource definition is front-loaded, and the pagination behavior is stated in one short clause. Every word earns 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 simple listing tool with two optional, fully documented parameters, an output schema, and annotations covering safety, the description is complete. It explains what the tool returns, the resource semantics, and how pagination works.
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 coverage is 100%, so the schema already documents limit and offset. The description reinforces the pagination behavior ('Returns 50 at a time; page with offset') but adds only minimal new meaning beyond what the parameter descriptions already state.
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 uses a specific verb ('List') and a clearly identified resource ('routing forms and funnels'), and explains what these are: qualification forms that route visitors. This makes it easy to distinguish from sibling tools like get_routing_form or create_routing_form.
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 clearly implies this tool is for retrieving a paginated list of routing forms, but it doesn't explicitly contrast it with get_routing_form for single-form lookup or other sibling list tools. The usage context is reasonable but relies on inference rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-idempotent creation action; the description adds valuable behavioral traits beyond that: the link is single-use, cannot be reshared, and requires no attendee details. These constraints materially shape how an agent should use the tool and are not derivable from annotations or schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler. The first sentence carries the core purpose and single-use behavior; the second adds two meaningful constraints (no attendee details, non-resharable). Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with annotations present, this is nearly complete: purpose, single-use behavior, input expectations, and sharing restriction are all covered. The only minor omission is what the response returns (presumably a URL), which is strongly implied by the title, and the absence of an output schema makes this a small but non-critical gap.
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 0%, so the description must compensate for meetingTypeId. It partially does by tying the link to 'a meeting type,' which clarifies the parameter's role, and the parameter name is self-explanatory. However, it doesn't state how to obtain a valid meetingTypeId (e.g., from list_meeting_types) or whether the type must be active, leaving a modest gap.
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?
States a specific verb ('Generate'), a specific resource (single-use booking link for a meeting type), and the user-facing purpose (someone chooses their own slot). The 'single-use' qualifier plus 'No attendee details are needed' clearly distinguishes it from siblings like book_appointment, which books directly with attendee information.
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?
Gives clear context for when this tool fits: when a meeting type exists and another person should self-select a slot without providing attendee details. It doesn't explicitly name alternatives or when-not-to-use conditions, but the stated constraints ('No attendee details are needed') effectively imply the boundary against booking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and readOnlyHint=false, and the description adds valuable context by stating that dependent event flows stop receiving events immediately. This goes beyond the binary annotation and alerts the agent to the cascading irreversibility of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded, and the second sentence adds a critical behavioral consequence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation with an existing output schema and annotations covering safety, the description is complete. It explains the action, the immediate effect, and there is no missing information an agent would need to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the webhookId parameter, but it does not mention it at all. The parameter name is self-explanatory and the schema defines it as a required string, but the description adds no value about its meaning or how to obtain it.
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 states a specific verb and resource, 'Delete a webhook endpoint,' which clearly distinguishes it from sibling tools like create_webhook and update_webhook. It also adds a meaningful consequence that reinforces what the operation does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is used when an existing webhook needs to be removed, and the immediate effect warning provides useful decision context. It does not explicitly name alternatives or when not to use it, but the purpose is unambiguous enough that an agent can infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaning beyond the readOnlyHint/idempotentHint annotations by explaining what the returned slotsStartUtc values represent and that they are the starts accepted by booking validation. This clarifies important semantics that an agent would otherwise have to infer. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core function is front-loaded, and the important caveat about calendar events is placed second. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with a high-quality schema, annotations, and an output schema present, the description covers the essential behavioral nuance and scope. It doesn't explain return format or pagination, but the output schema can carry that responsibility. The only slight gap is not explicitly addressing how start/end are interpreted, though the schema names them clearly.
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?
The input schema already documents all parameters with 100% coverage, including optional behaviors like meetingDuration and existingAppointmentId. The description does not add further parameter-level details, which is acceptable given the high schema coverage. Baseline of 3 applies.
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 uses a specific verb ('Return') and identifies the exact resource ('a meeting type's bookable starts') and scope ('within a date range'). It is clearly distinct from sibling tools like list_appointments or get_appointment. The added sentence about slotsStartUtc further grounds the purpose in what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is the tool to use when you need bookable start times for a meeting type, and it gives a scoping detail ('within a date range'). The warning that 'calendar events alone are not availability' implicitly steers agents away from treating calendar data as a substitute, which is a useful usage hint. However, it does not explicitly name any sibling tool as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readonlyHint=true and idempotentHint=true. The description adds valuable behavioral context by disclosing the return content: sent/opened/completed statuses, timestamps, and identification of unanswered recipients. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action, and every clause adds useful information. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description covers the core behavior and highlights a key use case. It could briefly mention the form must have been sent, but that is already implied by 'was sent to' and the sibling send_routing_form tool.
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?
There is one required parameter, formId, with no schema description and 0% schema coverage. The description doesn't explicitly describe formId, but the parameter name and the phrase 'a routing form' make its meaning reasonably clear. Still, the description doesn't compensate fully for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('who a routing form was sent to'), and adds distinguishing detail: statuses and timestamps. It is easily distinguishable from siblings like list_routing_forms and get_routing_form.
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 provides clear context for when the tool is relevant: after a routing form has been sent, to check recipient statuses and identify non-responders. However, it doesn't explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond those: a latency expectation ('Takes up to a minute'), a scoping behavior ('Reads a sample of a website' rather than the whole site), and reinforcement that the output is a non-persisted draft. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero filler: the first front-loads the core purpose and output composition, the second states the side-effect profile, the third states latency. The long component list earns its place because it tells the agent exactly what the draft will contain.
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?
With an output schema present, return-value details need not be restated. The description covers purpose, deliverable scope, side-effct profile, and latency. Minor gaps remain: failure behavior for unreachable websites and prerequisites are not mentioned, but these are edge cases for a tool whose schema and annotations already carry substantial context.
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 the baseline applies. The main description adds no parameter-specific meaning, but the schema itself is rich — especially useCase's 'Changes the brief it is designed against, not just its wording' and language's 'Restrict the pages read'. The description and schema together leave no parameter underspecified.
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 states a specific multi-part action ('Read a sample of a website and propose a complete assistant setup') and enumerates the deliverable's components: persona, welcome message, grounded instructions, qualification questions, quick actions, privacy/imprint links, and a knowledge probe. This clearly differentiates it from siblings like crawl_company_website (crawls only), get_mira_settings (reads current config), and update_mira_settings (mutates config).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool produces a settings draft for a website, and crucially states an exclusion — 'nothing is stored or configured' — which signals the agent this is not the tool for applying changes. However, it does not explicitly name alternatives (e.g., update_mira_settings for actually applying, crawl_company_website for just fetching pages), so the routing between siblings is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the safety profile is known. The description adds valuable behavioral details beyond the annotations: the operation sends to exactly one recipient, the response always contains publicUrl, and there is a rate limit of 20 per minute. It does not elaborate on what the destructive hint refers to, but the annotations cover that baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the first defines the action and outcomes, the second states the key response field, the third states the rate limit. No filler or redundant restating of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema, a moderately rich input schema, and annotations covering safety/idempotency, the description is nearly complete. It adds the rate limit and the publicUrl invariant, which are not in the structured data. A small gap is that it doesn not explain any prerequisites or exclusions for sending, but the overall package is sufficient for correct invocation.
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 coverage is 71%, so the description is not fully burdened but also has room to add parameter meaning. It reinforces the deliveryMethod enum by explaining email, SMS, and link mintung, and adds the 'one recipient' constraint. However, it doesn't clarify the semantics of formId or recipientName beyond their names, and the schema already documents most parameter details.
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 states a specific verb ('send') and resource ('routing form'), and clarifies the delivery modes (email, SMS, or link minting). It clearly differentiates this from sibling tools like create_routing_form, list_routing_forms, update_routing_form, and delete_routing_form, which involve different actions on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear delivery context: email, SMS, or link-only minting. It does not explicitly state when not to use this tool or name alternative tools, but for a send operation the scope is reasonably clear. The sibling list shows other form operations, and the description's delivery-mode breakdown helps an agent pick the right invocation path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=true, which aligns with this being a mutating update. The description adds critical behavioral detail beyond the schema and annotations: 'Only supplied fields change' clarifies partial-update semantics, and 'Tags replace the existing list rather than merging, so retained tags must be included' warns of a non-obvious replace behavior. This is genuinely useful and not visible in the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, tightly written, with the most important operational warning (tags replacement) stated explicitly. No fluff, no repetition of schema details, and the partial-update semantics are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating CRM update tool, the description explains the key non-obvious behavior: partial updates and tag replacement. It doesn't explicitly mention return values, but an output schema exists, so that burden is reduced. It also doesn't mention auth requirements or required permissions, but the annotations already indicate a destructive operation. The description is complete enough for correct invocation assuming the agent has contactId and desired fields.
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 0%, so the description must compensate. It doesn't describe individual parameters, but it gives crucial semantic guidance about the tags parameter and the overall partial-update behavior. Since there are 8 parameters and only tags behavior is clarified, the description does not fully compensate for the missing schema descriptions, but what it does say is valuable.
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?
States a specific verb and resource ('Update a CRM contact') and distinguishes itself from siblings like create_contact and delete_contact. The description's additional behavior note about tags differentiate it from other update operations within the same tool group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use it: updating an existing CRM contact, and because only supplied fields change, it is appropriate for partial updates. However, it does not explicitly name alternatives like create_contact or search_contacts, nor does it state when not to use it. The context is clear enough for an agent to select it among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by specifying exactly what gets destroyed: supplying qualifiers, fields, or funnelSteps replaces entire collections, and omitted items are deleted. It also clarifies partial update behavior when those collections are omitted, which is critical for an agent to avoid accidental data loss. This is strong behavioral disclosure directly tied to the tool's risk profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the operation, and the second delivers the critical behavioral warning without redundancy. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with an output schema, the description covers the most important operational risk—accidental deletion of collection items—and the partial-update semantics. The schema already documents skipForm fully, and the output schema covers return values. It could be slightly more complete by addressing structureType or offering explicit guidance on when to use this versus create_routing_form, but overall the key context is present.
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?
With only 11% schema description coverage, the description must compensate, and it does for the most dangerous parameters: qualifiers, fields, and funnelSteps are explained as full-replacement collections. It also clarifies that name, slug, and showProgressBar are updated individually. However, it does not add meaning for other parameters like structureType or skipForm, and the opaque array item schemas remain undefined, leaving a significant gap.
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 first sentence states a specific verb and resource: 'Update a routing form.' This clearly differentiates it from sibling tools like create_routing_form, delete_routing_form, and get_routing_form. The description also adds meaningful scope by explaining collection replacement behavior, so the agent knows exactly what operation is being performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying an existing routing form, and the update semantics are clear from the verb. However, it does not explicitly state when to use this tool over alternatives like create_routing_form, nor does it provide exclusion criteria or scenarios where another tool would be more appropriate. The usage guidance is therefore implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses upsert behavior: repeating the same question replaces the earlier answer instead of creating duplicates. This is valuable given destructiveHint=true, and it does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the operation, the rationale, and the critical replacement behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a full schema, output schema, and annotations, the description covers purpose, content style, and the only non-obvious behavioral rule (replacement). Nothing essential 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 coverage is 100%, so the schema already documents both parameters fully. The description adds no new parameter-level detail beyond the existing schema descriptions, so the baseline score of 3 applies.
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 names a specific action ('Add a question-and-answer pair'), a specific resource (the company's knowledge base), and a content constraint ('in the company's own words'). It clearly distinguishes this from sibling tools like search_company_knowledge or delete_knowledge_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the condition for use ('closes a visitor knowledge gap') and clarifies update semantics. It does not explicitly name alternative tools or exclusions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and readOnlyHint=false, so the description correctly aligns with mutation. It adds meaningful behavioral context beyond annotations: it notifies attendees, rejects requests lacking either attendeeId or cancelAll, and distinguishes response types (attendee_removed vs. cancelled). This proactively discloses key side effects, though it does not discuss cancelEntireSeries behavior or reverting actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It leads with the core action and notification effect, then immediately explains the two key usage modes and the rejection condition. Every sentence contributes to correct invocation, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main cancellation behaviors but omits the cancelEntireSeries parameter, which is crucial for recurring appointments. While the output schema exists and may detail responses, the description does not guide agents on when to use cancelEntireSeries vs. cancelAll. Given the tool's complexity (5 parameters), this gap leaves some ambiguity for recurring scenarios, so completeness is adequate but not full.
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?
With 80% schema coverage, the schema already documents most parameters, but the description enhances understanding of attendeeId and cancelAll by explaining their exclusive roles and the rejection rule when both are absent. This adds value beyond the schema's simple descriptions. It does not elaborate on reason or cancelEntireSeries, but the schema covers those sufficiently, so the parameter semantics are well addressed.
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 explicitly states the verb 'Cancel' and the resource 'appointment', and adds that it notifies attendees, making the purpose unmistakable. It clearly distinguishes between canceling a single attendee and the whole appointment, which differentiates it from sibling tools like reschedule_appointment or book_appointment. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage conditions for group bookings: attendeeId removes one person while cancelAll cancels the whole appointment, and requests with neither are rejected. This guides when to use which parameter. However, it omits the cancelEntireSeries parameter for recurring appointments and does not mention alternatives like reschedule_appointment, so it is not fully comprehensive but still offers strong situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description goes beyond these by disclosing exactly what is affected: the booking page stops working immediately, and existing appointments are not cancelled. This is valuable behavioral context about the consequences of the destructive action that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no redundancy. The core purpose is front-loaded, and the two following sentences add essential consequences without unnecessary detail.
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 single-parameter destructive operation with annotations covering the safety profile and an output schema present, the description covers the key behavioral outcomes: immediate deactivation of the booking page and preservation of existing appointments. No critical information for invoking the tool correctly 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 0%, and the description does not explicitly explain the meetingTypeId parameter. However, the phrase 'Delete a meeting type' implies that the sole parameter identifies the meeting type to delete, adding relational meaning beyond the schema's bare string type. It still does not elaborate on how to obtain or validate the ID, so the compensation is partial.
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 uses the specific verb 'Delete' with the resource 'a meeting type' and then clarifies the scope by stating that its booking page stops working immediately and existing appointments are not cancelled. This clearly distinguishes it from sibling tools like create_meeting_type, update_meeting_type, get_meeting_type, and list_meeting_types.
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 provides contextual behavior - the booking page stops working and existing appointments are not cancelled - which implies it is for permanently removing a meeting type without affecting current appointments. However, it does not explicitly name alternatives or state when not to use this tool, leaving the agent to infer that cancel_appointment or update_meeting_type might serve other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds the key real-world consequence that any already-shared link stops working. This goes beyond the structured hints and is exactly the sort of behavioral disclosure an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and followed by the most important consequence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool, the description plus annotations provide everything needed: what it deletes, the required identifier, and the external effect. An output schema is also present, so return-value details are not the description's job.
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?
The single required parameter formId has no description in the schema, and the description does not elaborate on it. However, the parameter name is self-explanatory and the tool's purpose makes its role obvious, so the gap is minor.
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?
States a specific verb and resource: 'Delete a routing form.' This clearly distinguishes it from sibling actions like update, create, get, list, and send on routing forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action is self-explanatory as a deletion tool, and the added consequence about shared links provides clear context for when it is appropriate. It does not explicitly contrast with alternatives, but the purpose alone gives sufficient routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by specifying that it returns a summary of activity and surfaces only unanswered questions, framing results as gap indicators. This goes beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the core action, and the second explains the practical value. Nothing duplicates the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional documented parameter and an output schema, the description provides the purpose, the distinguishing data (unanswered questions), and the follow-up action (identifying knowledge gaps). An agent has everything needed to select and invoke it correctly.
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?
The schema description fully covers the only parameter ('Window in days, 1-90. Defaults to 7.'), so the description doesn't need to add parameter details. Baseline 3 applies since schema coverage is 100% and no parameter-specific information is missing.
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 states a specific action ('Summarise'), a clear resource ('recent website assistant activity'), and a distinctive focus ('visitor questions it could not answer'). This clearly differentiates it from siblings like list_knowledge_documents or answer_visitor_question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence ('Unanswered questions identify gaps suitable for new knowledge entries') implies the intended use case: finding knowledge gaps before adding new entries. It provides clear context but does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds value by specifying the authenticated-user scope and the exact fields returned, which helps the agent anticipate the response. It goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the resource and then provides a compact list of relevant response contents. There is no filler, repetition, or redundant explanation.
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 no-parameter, read-only getter with an output schema and strong annotations, the description is complete. It conveys what the tool returns and for whom, while the output schema can carry the detailed return structure. Nothing essential 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?
The tool has zero parameters, and the schema description coverage is 100%, so there is nothing for the description to add about parameter semantics. The baseline for zero-parameter tools is 4, and the description appropriately says nothing about inputs.
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 names a specific resource, 'the authenticated user's personal booking page,' and enumerates its concrete contents: colours, header image, description, profile links, and meeting-type order. Together with the verb in the title ('Get'), this is unambiguous and distinct from related tools like get_me or list_meeting_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: retrieve the current user's booking page configuration. However, it does not explicitly state when to prefer this tool over alternatives such as get_me or list_meeting_types, nor does it mention exclusions or edge cases. It offers clear context but no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the checklist stages and use timing, but it does not disclose additional behavioral traits such as authentication needs or rate limits, though none are expected for this read-only status endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences. The first sentence front-loads exactly what is returned, and the second adds useful detail about the result contents and when it is appropriate to call, with no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an empty input schema, a rich output schema, and annotations covering safety, the description provides everything else an agent needs: the exact checklist domains, the per-stage status/next-move content, and a clear statement of applicability before or after setup changes. Nothing critical 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?
The tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameters, and it correctly avoids doing so; it instead focuses on the return content and use case.
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 states a specific verb ('Return') and a specific resource: the dashboard launch checklist for bookable meeting type, assistant, knowledge, test drive, installation, and live state. This clearly distinguishes it from sibling status tools like get_crawl_status, which targets crawling rather than setup stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting the result is 'suitable before or after setup changes,' which tells the agent when this tool is useful. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context about the authenticated-user scope and cost/precision trade-offs, but does not describe return shape or any additional behavioral traits. This is consistent with the calibration example for covered tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The core action is front-loaded, and the differentiating rationale is provided in the second sentence. Every word earns 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 zero-parameter read-only query with an output schema and strong annotations, the description is complete. It specifies the user scope, the time range, and the advantage over the alternative. 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?
The tool has zero parameters, so the description does not need to elaborate on parameter meaning. Baseline for 0 parameters is 4; the description appropriately says nothing about parameters.
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 states a specific verb and resource: 'Return today's appointments for the authenticated user.' It also distinguishes itself from a general date-filtered appointment list by emphasizing it is cheaper and more precise, which clearly separates it from siblings like list_appointments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: use this when you need today's appointments for the authenticated user and want a cheaper, more precise query than the general date-filtered list. It implies the alternative without explicitly naming list_appointments or stating when not to use the general list, so it stops just short of full explicitness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds concrete behavioral detail: 'Returns 50 at a time with offset pagination,' which tells the agent how results are delivered and how to iterate. This is useful context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded, and the pagination behavior is stated in a compact second sentence. Every word earns 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 simple paginated list tool with fully documented parameters, a rich output schema, and read-only/idempotent annotations, the description is complete. An agent has everything needed to invoke it correctly and understand the result shape.
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%, with both limit and offset fully documented including defaults and ranges. The description's pagination mention aligns with the schema but does not add new semantic meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 states a specific action ('List') and a precise resource ('reusable form fields shared across routing forms'), which distinguishes it clearly from sibling tools like list_routing_forms and create_data_field. The additional note about fields matching a planned addition reinforces its purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by indicating this is used to discover existing reusable fields, including ones that may match a planned addition. It does not explicitly name alternatives or state when not to use it, but the context strongly implies the intended workflow alongside create_data_field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent, destructive operation, and the description's 'send' wording aligns with that. The description adds valuable behavioral context beyond annotations by specifying the rate limit (5 per 5 minutes) and the one-off nature of the email, which helps the agent plan around side effects and retries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler, with the primary purpose front-loaded. Each sentence adds distinct value: what the email is for, the required input context, and the rate limit. This is a model of concise, structured tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with a complete input schema and an output schema, the description covers everything needed for correct invocation: purpose, content examples, the prerequisite attendeeId source, and rate limiting. Side-effect expectations are covered by annotations. There are no missing details that would prevent an agent from calling the tool safely.
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 the schema already documents attendeeId, title, and content sufficiently. The description repeats the attendeeId source ('from appointment details') and gives examples of content types, but adds little beyond the schema's own descriptions. Baseline 3 is appropriate because the schema does the heavy lifting.
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 states a specific action ('send a one-off email') and a specific resource ('to an attendee'), with concrete examples of acceptable content. This clearly distinguishes it from sibling tools like book_appointment or send_routing_form, which involve different workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: one-off emails such as follow-ups, preparation notes, or directions. It also highlights a prerequisite (attendeeId from appointment details) and a rate limit, which is useful operational guidance. It does not explicitly name alternative tools or exclusions, but that is not a major gap given the tool's unique purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses the operation's mechanism ('Fetch a page') and the precise boolean semantics of the result. It doesn't cover edge cases like redirects or JS rendering, but the annotations already establish it as a safe, non-destructive read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the action is front-loaded, the success criterion is explicit, and the usage context is appended in a single clarifying clause. Every sentence contributes useful information.
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?
The tool has one self-describing parameter, rich annotations, and an output schema. The description covers what it does, when to run it, and what 'installed' means, leaving no essential gap for an agent to select or invoke it correctly.
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 coverage is 100%, so the url parameter is fully documented in the input schema. The description adds a mild contextual nuance ('customer's website') but does not need to elaborate further for a single, simple parameter.
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 states a specific verb ('verify') on a specific resource (the customer's website page) and defines the exact success condition: 'installed is true only when both elements are present.' This clearly distinguishes it from sibling tools like get_mira_widget_embed or crawl_company_website.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage trigger: 'Intended after the snippet is installed.' It does not name alternatives or exclusions, but the context is clear enough given the distinct purpose and single parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation via readOnlyHint=false and destructiveHint=true, and the description adds meaningful behavioral detail: it modifies the appointment by adding a guest, triggers invitation/update delivery, and limits calls to one guest. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core action is front-loaded and the constraints are packed efficiently into the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation with an output schema and annotations, the description covers the essential information: action, prerequisite, and per-call limit. It could mention duplicate handling or permanence, but those are not critical to making a correct first call.
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 description coverage is only 33%, but the description compensates by explaining the attendeeId's origin ('returned with appointment details') and the email's purpose ('receive the invitation and updates'). appointmentId is not detailed, but its role is obvious from the tool name and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add one guest email to an appointment'. It also clarifies the downstream effect ('so they receive the invitation and updates'), making the tool's purpose unambiguous and distinct from sibling tools like create_contact or book_appointment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite: 'Requires the attendeeId returned with appointment details', and a usage constraint: 'accepts one guest per call'. It does not explicitly name alternatives or state when not to use the tool, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by disclosing the 1000-contact batch limit, the 3-calls-per-minute rate limit, and the per-contact requirement of email or phoneNumber. It does not discuss idempotency or partial-failure behavior, but the provided details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. It front-loads the primary purpose and then adds essential constraints, with every sentence contributing useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the structured schema defines the fields, the description provides enough information to invoke the tool correctly: required contact info, batch size, and rate limit. Minor gaps remain around failure semantics and deduplication, but they do not block correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does by stating that each contact in the array must have email or phoneNumber, a critical constraint not encoded in the JSON schema. It also summarizes the batch size limit, adding value beyond the parameter names.
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 'Create many contacts in one import', which names a specific verb, resource, and mode. This clearly differentiates it from the sibling create_contact tool, which handles single contact creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when many contacts need to be created in a single import. It also mentions constraints, but it does not explicitly name alternatives like create_contact or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those annotations by stating the return includes linked appointments and form answers, and by explaining that attendeeId links booking identity to the stored contact. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the tool's purpose, scope, return contents, and input alternatives with no filler. The main action is front-loaded, and the second sentence adds only essential identifier semantics.
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?
An output schema is present, so return-value details do not need to be spelled out, and annotations cover the safety profile. The description covers purpose, output contents, and accepted identifiers. The only notable gap is not explicitly stating that one of contactId or attendeeId must be supplied, especially since the schema marks both as optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents attendeeId; contactId has no description and schema coverage is 50%. The description compensates by clarifying that either identifier can be used and that attendeeId comes from an appointment context. It does not explicitly state that exactly one ID is required, but it adds meaningful meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return a full contact record including linked appointments and form answers.' This clearly distinguishes get_contact from sibling tools like search_contacts or get_me, and the mention of accepting contactId or attendeeId further narrows its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to invoke the tool: when you already have a contactId or an attendeeId from an appointment. It does not explicitly state when not to use it or name an alternative such as search_contacts, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint true) and non-read-only, and the description adds valuable behavioral detail beyond that: duration is unchanged, availability is validated unless ignoreAvailability is set, and a successful response echoes the new time as startUtc. This gives the agent concrete expectations for side effects and response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each conveying essential information without redundancy. The core action is front-loaded ('Move an appointment to a new start time'), followed by concise behavioral notes.
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?
With an output schema present and annotations covering read-only/destructive hints, the description provides enough operational context: what changes, what remains constant, when availability is enforced, and what the response contains. It does not elaborate on permissions or notifications, but these are not required for invoking the tool correctely.
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 description coverage is 67% and the description compensates meaningfully. It clarifies that 'start' is a new start time, that duration remains fixed, and that ignoreAvailability controls whether availability validation is bypassed. It also ties the response field startUtc to the new time, deepening understanding of the start parameter. AppointmentId's role is implicitly clear from the verb 'Move an appointment'.
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 states a specific verb ('Move') and resource ('an appointment') with the exact outcome ('to a new start time'). It clearly separates from sibling tools like book_appointment or cancel_appointment, which perform different lifecycle operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for rescheduling an existing appointment rather than creating or canceling one. It does not explicitly name alternatives or state exclusions, but the operation is unambiguous and distinct from siblings like book_appointment and cancel_appointment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true already present, the description adds valuable behavioral context: 'Only supplied fields change' gives partial-update semantics and 'null clears one' exposes the destructive null behavior explicitly. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the first states the action, the second explains why content must be supplied, and the third gives the exact mutation semantics. No filler and no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter mutation with an output schema and annotations already covering safety, the description is complete: it covers source, format, partial updates, and clear semantics. It could have explicitly said that new values overwrite existing stored content, but 'only supplied fields change' conveys this sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes summary and transcription as markdown-or-null, and the description reinforces that with partial-update semantics: only supplied fields change and null clears. The appointmentId parameter is not elaborated, but coverage is 67% and the description clarifies how the nullable parameters behave.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Attach ... to an appointment' and names exactly what content is allowed (transcript and/or AI summary in markdown). It also clarifies that the tool is not storing a Meetergo recording, which distinguishes this content-storage tool from recording concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool is used to attach caller-supplied transcript/summary content to an appointment, and the 'meetergo does not record calls' note provides a concrete condition for when this tool is needed. It does not explicitly name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, which establish safety. The description adds meaningful behavioral context: it is low-cost, returns plan tier/caps conditionally, and explicitly notes that plan data does not gate connections. This goes beyond the annotations and helps set expectations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The primary return value is stated first, followed by the usage context and an important caveat. Every sentence earns its place, making it easy to read and quick to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete. It covers what is returned, when it is appropriate to call, and clarifies the meaning of plan data. An agent can confidently invoke it without needing additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully covered (100%), so there is no need for parameter-level explanation. The description correctly focuses on return values. Per the baseline for 0-param tools, a score of 4 is appropriate; the description could mention that no input is required, but the empty schema already implies this.
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 states a specific verb ('Return') and resource ('authenticated account'), plus the optional plan tier and caps. It clearly conveys the tool's purpose and differentiates it from calendar-related siblings by framing it as an authentication check rather than a data retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: as a low-cost authentication check to distinguish a bad token from an empty calendar. It also explains that plan data provides limits but does not gate the connection, helping agents understand its role. However, it does not explicitly state exclusions or alternatives, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond those annotations: it returns the 'resolved' configuration (not just raw input), includes a server-minted publicKey, and characterizes the value as a snapshot suitable for rollback, which tells the agent the output is comprehensive enough to restore from.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first front-loads the action and scope, the second provides the key usage nuance. Every phrase earns its place, and no structured data is unnecessarily repeated.
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?
With zero parameters, a rich output schema, and annotations covering safety and idempotency, the description covers everything an agent needs: what is returned, what categories of data are included, and why to call it (rollback snapshot). The mention of the publicKey is particularly valuable because it confirms an authentication-relevant field is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. Baseline for a parameterless tool is 4, and the description appropriately focuses on the output rather than inventing parameter guidance.
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 names a specific verb ('Return') and a specific resource ('the company's resolved Mira configuration'), then enumerates the exact contents: master switch, assistant profiles, chat widget with server-minted publicKey, and data-access toggles. This clearly distinguishes it from the narrower sibling get_mira_widget_embed and from mutation tools like update_mira_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say 'use this instead of X', but it provides a clear usage context by stating the result is suitable as a rollback snapshot, which implies it should be called before changes to capture a restore point. Among siblings, this is the read-only retrieval counterpart to update_mira_settings and restore_mira_settings, which is inferable but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context by explaining the publicKey requirement and the preview URL use case, which helps the agent understand expected behavior and preconditions without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the primary purpose front-loaded and the prerequisite stated immediately after. Every clause contributes useful information.
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 no-parameter, read-only tool with an output schema and safety annotations, the description is complete: it explains what is returned, where the snippet is inserted, the testing use case, and the required prerequisite. Nothing essential 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?
The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds relevant semantic context by referencing the webChat publicKey as a prerequisite, even though it is not an input parameter, clarifying that no additional arguments are needed.
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 states a specific verb ('Return'), a concrete resource ('embed snippet a website owner pastes before </body>'), and an additional deliverable ('preview URL'). This clearly distinguishes it from sibling tools like get_mira_settings or verify_widget_install by focusing on the installation snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is useful, including testing a saved-but-disabled widget, and states the prerequisite webChat publicKey. It does not explicitly name alternative tools or exclusions, but the scenario is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the existing annotations. It reveals that the tool 'reads only the public profile', 'never modifies the source account', is 'additive', and that 'running it twice creates duplicates'. These details explain side effects and safety margins, and they align with the annotations rather than contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main action appears first, followed by key constraints, side effects, and result summary. Every sentence contributes meaningful information—no filler or repetition.
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 single-parameter import tool with an output schema, the description covers everything needed: source detection, behavior, side effects, duplicates, and response contents. Nothing essential 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?
The schema already provides complete coverage (100%) for the single `url` parameter, including format, example, and provider-detection behavior. The description adds value by naming Calendly and confirming the import source, but it largely restates what the schema already documents, so the baseline of 3 is appropriate.
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 precise action and target: 'Recreate an existing public booking page in meetergo from its URL.' It clearly defines the input (URL), the operation (import), and the outcome (creates one meeting type per visible event type), making it easily distinguishable from siblings like create_meeting_type or update_meeting_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: importing a public booking page from Calendly or another recognized scheduler. It describes the read-only source behavior and the mapping to meeting types, but it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating the result shows whether a host has a calendar attached and supports availability diagnosis, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action and resource appear first, followed by provider detail and practical value, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only list tool with an output schema and strong annotations, the description is complete. It states what is listed, which providers are covered, and what the result can be used for, leaving no meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them automatically, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4.
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 uses a specific verb 'List' and names the resource 'connected calendars' with concrete providers (Google, Outlook, CalDAV). It clearly distinguishes this tool from appointment, contact, and webhook siblings in the group.
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 says the result 'supports availability diagnosis,' providing a clear use case for when the output matters. However, it does not explicitly name alternatives or when-not-to-use, though no close sibling exists for this task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context about scope ('authenticated user's'), status ('bookable'), and what data is included (identifier, duration, host data). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action, scope, and key returned fields without any filler. Every component adds value.
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 parameterless read-only listing operation, the description is complete. It identifies what is listed, whose data it lists, and which fields matter for downstream booking, while the output schema and annotations cover return structure and safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. Schema coverage is 100% and the description correctly avoids inventing parameter details.
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 states a specific verb and resource: 'List the authenticated user's bookable meeting types' and clarifies that it returns identifier, duration, and host data. This distinguishes it from sibling tools like get_meeting_type (single type) and book_appointment (which consumes this data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: enumerate bookable meeting types before making a booking, or to fetch IDs/durations/host data. It does not explicitly contrast this with get_meeting_type or other meeting-type tools, but the list vs. single distinction is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context beyond those annotations by revealing the six-endpoint limit and that the result indicates current subscription status relative to that cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action is front-loaded, and the additional constraint about the six-endpoint maximum is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only list operation, the description covers the essential behavior, the annotations cover safety, and the presence of an output schema means return-value documentation is not the description's job. Nothing important 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?
The tool has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies, and the description does not introduce any parameter-like ambiguity.
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 uses a specific verb ('List') and resource ('webhook endpoints for the company'), clearly distinguishing this from sibling tools that create, update, or delete webhooks. It also adds a useful detail about comparing subscriptions against the six-endpoint maximum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear from the description and context: call this when you need to view existing webhook subscriptions. It does not explicitly name alternatives or exclusions, but the sibling set makes the read-vs-write distinction obvious, so the lack of explicit routing is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by noting that results come from the same retrieval path Mira uses for visitor answers, which sets expectations about result semantics without repeating annotation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action, retrieval semantics, and intended use case are front-loaded, and every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, strong safety annotations, and presence of an output schema, nothing essential is missing. The description clearly explains what the tool does, why an agent would call it, and how it relates to Mira's retrieval behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents k well ('Chunks to return, default 5') and query minimally as a string. The description adds meaning by indicating the query should represent a visitor-style question used to validate grounded coverage, compensating for the low schema coverage on the query parameter.
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?
States a specific verb ('search'), specific resource ('knowledge base'), and a distinctive mechanism ('semantic search using the same retrieval Mira uses for visitor answers'). It also frames the exact use case, validating grounded coverage before launch, which distinguishes it from the sibling answer_visitor_question.
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?
Clearly positions when to use the tool: before launch, to validate grounded coverage for a question. It does not explicitly name alternatives or exclusions, so it falls short of a 5, but the context is concrete enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that the operation is a replacement, not an append, and warns that retained existing text must be included. This adds meaningful behavioral context on top of the destructiveHint annotation by clarifying exactly what gets overwritten. It does not discuss reversibility or permissions, but the core destructive behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the key verb and resource, with the critical replacement caveat immediately after. There is no redundant or vague wording.
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?
The tool is simple: two required parameters, no nested objects, and an output schema exists. The description, combined with annotations, provides all essential operational details — what the tool does, what the note parameter must contain, and that the update is destructive and non-idempotent. No significant gap remains for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by defining note as the full replacement content and emphasizing that existing text must be carried over. appointmentId is not described, but its property name and the tool context make its role obvious. For only two simple string parameters, this is adequate semantic guidance.
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 states a specific verb ('Replace'), a clear resource ('host-side note on an appointment'), and the intended content ('call preparation or an outcome summary'). This makes the tool easy to distinguish from appointment scheduling, cancellation, or transcription tools. Even without naming alternatives, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when this tool is appropriate: when the host-side appointment note should be replaced with preparation or outcome text. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (destructiveHint=true, readOnlyHint=false) by disclosing key behaviors: omitted fields keep their value, webChat merges field-by-field, assistantProfiles replaces the entire list, minting of the widget publicKey even with enabled=false (draft state), and response includes previous/current settings for rollback. This is rich context that helps an agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence block that front-loads the core purpose and access level, then packs essential behavioral caveats. No wasted words; every sentence earns its place with actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, many fields) and existing output schema, the description covers the most critical nuances: partial update, merge vs replace, draft state, and rollback. A minor gap is that dataAccess behavior isn't explicitly specified (whether it merges or replaces), but the general 'omitted fields keep value' rule and schema description partially cover it. Overall, it's sufficient for correct usage.
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 80%, so baseline is 3. The description adds significant meaning beyond the schema: it clarifies merge semantics for webChat and replacement for assistantProfiles, and explains the draft state behavior tied to webChat fields. The schema itself already describes many fields, but the description's behavioral notes are valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Partially update Mira configuration'. It immediately distinguishes itself from sibling tools like get_mira_settings (read) and restore_mira_settings (likely full reset) by clarifying partial update semantics. The admin-only qualifier adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when this tool is appropriate: partial updates, admin-only access, and specific merge/replace behavior for webChat vs assistantProfiles. It doesn't explicitly name alternatives or exclusions, but the behavioral details imply common usage scenarios (e.g., tweaking individual settings without a full rewrite).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (not read-only, destructive), the description discloses concrete side effects and state semantics: it creates a real appointment, sends invitations, rejects invalid starts, and clarifies that pending_confirmation means the appointment is not booked. This is exactly the behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: core action, validation rule, result-state interpretation, and a required-field condition. The most important purpose is front-loaded, with no filler.
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 14-parameter mutation with an output schema and annotations, the description covers the essential operational caveats: availability-sourced starts, rejection of invalid starts, ambiguity between confirmed and pending states, and mandatory attendee name input. Nothing critical is left to guesswork.
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?
With 71% schema coverage, the description adds meaningful cross-parameter logic that the schema cannot express: the start must come from availability results, and fullName can substitute for firstName plus lastName. It does not re-explain every parameter, but it compensates for the key conditional requirements.
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 action ('Create a real appointment') on a clear resource (an appointment for an availability start) and explicitly says it sends invitations. It also differentiates from scheduling-adjacent siblings by tying booking to availability results and noting unlisted starts are rejected.
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 clearly indicates when to use the tool: only for starts present in meeting type availability results, with an unlisted start rejected. It does not explicitly name alternatives like reschedule_appointment or create_one_time_booking_link, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining that server-managed fields such as publicKey and mirrored channels.webChat list are stripped automatically. It also discloses a subtle behavioral outcome: the minted publicKey survives rollback and remains harmless while the widget is disabled. This is valuable edge-case context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. Each sentence earns its place: the first states the core action, the second identifies the automatic stripping behavior, and the third clarifies a nuanced exception. The structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, a high-coverage schema, and an output schema, the description covers the essential operational details: what snapshot to provide, how server-managed fields are handled, and the surprising publicKey behavior. The destructive nature is already declared in annotations, so nothing critical 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% and the schema already describes the settings parameter as 'The full settings snapshot to restore. Pass it back unmodified.' The tool description adds semantic value by clarifying the snapshot must be a previously returned one and that server-managed fields will be stripped, which helps the agent understand what 'unmodified' means in practice.
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 uses the specific verb 'Roll back' and identifies the exact resource: Mira configuration restored from a previously returned settings snapshot. This clearly differentiates the tool from update_mira_settings and other sibling tools by scoping it to snapshot restoration rather than general updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when rolling back to a previously returned settings snapshot. It does not explicitly name alternative tools or state when not to use it, but the phrase 'previously returned settings snapshot' sets a precise prerequisite that guides correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavior beyond the sparse annotations: duration ('about a minute'), rate limit ('a few runs per hour'), side-effect profile in preview mode ('creates no bookings or emails'), and persistence ('stored result feeds the launch checklist'). This gives an agent a strong mental model of the tool's runtime and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences of dense, useful information. It front-loads the core action and output, then adds constraints and context, with every sentence earning its place. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description covers the essential operational context: what it does, what it returns conceptually, side effects, prerequisites, time cost, rate limits, and downstream use. Nothing critical is missing for an agent to decide to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. There is no parameter semantics to document, and the description appropriately focuses on behavior rather than adding unnecessary parameter detail.
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 states a specific action ('Send scripted visitors to the saved assistant') and a clear deliverable ('return pass/fail verdicts with full transcripts'). It also names the visitor types (buyer, callback lead, adversarial visitor), making the tool's purpose concrete and distinguishable from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: it feeds the launch checklist and preview mode is safe because it creates no bookings or emails and requires no live widget. It does not explicitly name alternatives or exclusions, but the tool is unique among siblings and the usage context is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![meetergo-mcp-server MCP server](https://glama.ai/mcp/servers/meetergo/meetergo-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/meetergo/meetergo-mcp-server)

Score Badge

Copy to your README.md:

[![meetergo-mcp-server MCP server](https://glama.ai/mcp/servers/meetergo/meetergo-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/meetergo/meetergo-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/meetergo/meetergo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server