notion-calendar-mcp

by felipeorlando

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct resource and action, and descriptions generally clarify intent. However, get_calendar_lists vs get_calendars and get_contacts vs get_people are close enough that an agent could misselect without reading carefully.
Naming Consistency4/5
The dominant verb_noun pattern (get_, create_, update_, delete_) is consistent and readable. Minor deviations like insert_calendar_list, rsvp_event, and incremental_sync break the pattern slightly but are not chaotic.
Tool Count2/5
At 30 tools, this exceeds the 25+ threshold and feels heavy even for a calendar/scheduling domain. Several calendar-listing and contact-lookup tools could reasonably be consolidated.
Completeness4/5
The surface covers events, calendars, holds, preferences, contacts, and sync well, with create/read/update/delete coverage for the main resources. Minor gaps exist, such as no dedicated create_calendar or synchronization-management tools, but core workflows are supported.
Average 4.3/5 across 30 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, and the description aligns with those. It adds some useful behavioral context, such as the sidebar-list nature and that the calendar summary/name comes first, but it does not disclose return details, pagination, or any edge cases beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then the usage context and request shape. All sentences add value, though the request-format sentence is somewhat terse and reads more like a code comment.
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 single parameter and simple list operation, the description covers the key context: when to call, what request to send, and a hint about the response ordering. No output schema exists, so a bit more detail about the exact response fields would improve completeness, but the description is sufficient for basic 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?
Schema coverage is 0%, so the description carries the burden of explaining queries_json. It does this well by stating 'queries_json: JSON array' and giving the shape {queries:[{provider, accountId}]}, which adds essential meaning beyond the raw schema.
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 ('List calendars') and the resource scope ('for one or more accounts'), and adds the purpose of obtaining calendarId values. However, it does not explicitly differentiate this from sibling tools like get_calendars or get_synchronized_calendars, though 'sidebar calendar list' hints at some distinction.
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 explicit usage context: 'Call after get_user when you need calendarId values.' This tells an agent when to invoke the tool, but it does not mention when not to use it or name any alternative tools, so it falls 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?
The readOnlyHint annotation already flags this as a safe read operation, and the description is consistent with that. It adds useful context by stating the endpoint ('POST /v2/getSynchronizedCalendars {}') and clarifying that the operation concerns synchronized/mirrored calendars, not general calendars.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are efficient and front-loaded, but the endpoint line mostly repeats the tool name and the cryptic 'Name first' fragment adds confusion rather than clarity. Some content could be trimmed or clarified.
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 zero-parameter, read-only listing tool, the description covers what it lists and when to call it. There is no output schema, but the lack of a detailed return-format explanation is a minor gap given the simplicity of the operation.
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 no parameter meaning to add. The description even shows the empty request body, which is sufficient. The baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('synchronized/mirrored calendars'), and adds the context of 'sync links between accounts.' It is not as strong as explicitly naming a sibling alternative, but the meaning 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 explicitly says 'Call when inspecting Calendar sync links between accounts,' providing a clear trigger condition. It does not discuss when not to use it or name an alternative, but the usage context is specific enough for an agent to route correctly among the many get_* siblings.
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 mark the operation as non-read-only and non-destructive, and the description adds the POST endpoint and required payload constraints. It does not disclose response behavior, side effects, authorization needs, or rate considerations, so the extra behavioral context is moderate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action, endpoint, and main parameter requirement. The closing instruction 'Alias/title first' is cryptic and would benefit from clarification, but overall the text is efficiently structured without redundant filler.
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?
For a simple one-parameter creation tool, the description covers the trigger, endpoint, and key payload fields. However, the vague 'usual Hold fields,' the ambiguous 'Alias/title first' phrase, and the absence of any response or error behavior leave meaningful gaps for an agent trying to invoke 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?
The schema provides only a single opaque string parameter, hold_json, with 0% description coverage. The description compensates by naming required fields (id, timeRanges, userPrimaryTimeZone) and referencing 'usual Hold fields,' though the latter remains vague and no format or example is supplied.
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?
Opens with a concrete verb-resource pair ('Create a Hold scheduling page') and names the HTTP endpoint, making the tool's function immediately clear. It is also easily distinguishable from sibling tools like get_hold, update_hold, and delete_hold because it explicitly targets creation of a new booking link.
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 trigger condition: 'Call when the user wants a new booking link.' It does not, however, mention sibling alternatives or explain when not to use this tool, 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 destructiveHint=true and readOnlyHint=false, and the description strengthens that by explicitly warning 'Destructive — confirm with the user first.' It also reveals the exact HTTP endpoint, which adds behavioral context 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?
The description is very concise: one sentence stating the action, the endpoint, and the critical safety warning. Every part earns its place and no unnecessary detail is included.
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-parameter delete operation, the description provides the essential information: what to delete, which ID to use, the endpoint, and the destructive nature requiring confirmation. It does not describe the response or potential errors, but that is less critical given the tool's simplicity and the safety annotations.
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 0% schema description coverage, the description carries some burden for explaining hold_id. It mentions 'by holdId' and includes {holdId} in the endpoint, which clarifies that the parameter is the hold's identifier, but it adds no format, example, or additional constraints beyond what the parameter name and title already imply.
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 operation ('Delete a Hold') and the resource identifier ('by holdId'), and the destructive warning makes it distinct from read-only or update siblings like get_hold and update_hold. The endpoint is also included for precision.
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 gives a clear usage warning ('Destructive — confirm with the user first'), which is helpful, but it does not explicitly state when to prefer this tool over alternatives such as update_hold or create_hold. The usage context is implied by the verb but not fully elaborated.
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, openWorldHint=true, and destructiveHint=false, and the description adds meaningful behavior beyond that: it normalizes and exports partial event data into an ICS-oriented shape. It does not go into return format or idempotency, but the annotations reduce the burden and the 'normalize/export' description gives a clear sense of the operation.
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: it states the purpose first, then the endpoint, then the parameter shape, then the trigger condition. Every sentence contributes useful information and there is no filler.
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?
For a simple one-parameter tool with annotations already covering safety, the description covers purpose, usage, and basic parameter semantics. However, it does not explain the return/result of the export or clarify the JSON-encoding issue between the string schema and the described array, leaving an important operational gap.
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 coverage is 0%, so the description must compensate. It does add some value by listing the kinds of fields (id/start/end/summary) and calling the value an array of partial events, but it conflicts with the schema, which declares events_json as a string, and the POST example uses 'events:[...]' rather than 'events_json'. This ambiguity could mislead an agent about how to serialize the 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 uses a specific verb ('normalize/export') and identifies the resource ('partial event objects') with a distinct shape ('ICS-oriented shape'). It is clearly differentiated from sibling tools like get_events, search_events, and create_event, since none of them are described as export/normalization 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 explicitly states when to call the tool: 'Call when packaging events for export.' It provides clear context for the intended use case, though it does not explicitly discuss when not to use it or name an alternative 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 destructiveHint=false, and the description adds useful context: pagination, the POST endpoint, optional parameters, and the expected display fields (name/email first). This 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 three short sentences with no filler. Purpose, endpoint, usage context, and output expectation are all packed efficiently and 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 simple paginated list endpoint with no required parameters and no output schema, this description provides sufficient guidance to invoke the tool correctly. It could be stronger by clarifying pagination behavior or the relationship to get_contacts, but it is largely complete for its complexity.
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%, but the endpoint signature {accountIds?, cursor?, limit?} clarifies the meaning of account_ids_json, cursor, and limit. Property names are self-explanatory, yet the description does not explain the JSON format for account_ids_json or cursor semantics in detail.
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 tool lists people/contacts from connected accounts and even includes the exact endpoint. It is distinguishable from most siblings, though get_contacts exists as a potentially overlapping sibling and no differentiation is provided.
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 condition: 'Call when searching attendees by directory.' This tells the agent when to use it, but it does not discuss when not to use it or contrast it with alternatives like get_contacts.
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 this is a mutating, non-destructive, open-world operation. The description adds the concrete endpoint and payload shape ('POST /v2/insertCalendarList {mutation:{provider, accountId, calendarId, calendarData?}}'), which is useful. However, it does not disclose side effects, permissions, or what happens if the calendar already 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?
The description is compact and front-loaded: purpose first, then endpoint shape, then usage trigger. Every sentence contributes meaningful information 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 one-parameter tool with no output schema, the description covers the operation, the request format, the key payload fields, and the when-to-use context. It is missing return behavior and full field semantics, but those are less critical for such a simple insert-like 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?
With 0% schema description coverage, the description must compensate for the bare 'mutation_json' string parameter. It does provide a useful nested object shape, but it also says 'mutation_json: JSON object' while the schema types it as a string, leaving ambiguity about whether the agent should send an object or a JSON-encoded string.
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: 'Subscribe/add a calendar to the user's calendar list.' This clearly identifies the operation and distinguishes it from siblings like get_calendar_lists, update_calendars, and delete_calendar_list. The additional phrase 'Call when adding a shared calendar' cements the intended purpose.
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 explicitly says 'Call when adding a shared calendar,' giving a clear condition for use. It does not enumerate alternatives, but the sibling set and the insert/delete naming convention make the contrast 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=true and destructiveHint=false, so the safety profile is covered. The description adds useful operational detail beyond annotations: the endpoint, cross-account/calendar scope, time-range bounds, and that results begin with title/summary. It does not contradict 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?
The description is compact and front-loaded with the core purpose, then gives a usage trigger and key parameter details. Each sentence contributes useful information, though the endpoint string is somewhat redundant with the tool's function.
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?
There is no output schema, and the description only hints at return content with 'Title/summary first.' It does not explain pagination, result limits, or response shape beyond that. For a moderately complex search tool with annotations covering safety, this is adequate but not fully complete.
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 carry parameter meaning. It explains time_min/time_max as ms epoch and accounts_json as an array with accountId and calendarIds, which is valuable. However, it leaves query, limit, and user_time_zone unexplained, so parameter semantics are only partially compensated.
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 does full-text search of events across accounts/calendars in a time range, using a specific verb and resource. This distinguishes it from sibling tools like get_events, which imply list/retrieve behavior rather than keyword search.
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 trigger: 'Call when the user asks to find meetings by keyword.' This gives clear context for when to select the tool, though it does not explicitly contrast it with alternatives such as get_events or list-style browsing.
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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the endpoint, time range, and calendar identifiers, but does not disclose output shape, pagination, or potential limitations. Given the annotations, a score of 3 is appropriate.
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: purpose, usage context, and parameter semantics. It is front-loaded and every sentence adds value without 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 read-only availability tool, the description covers the key context: when to call it, what it returns at a high level, the endpoint, and all parameter formats. Since there is no output schema, the exact free/busy block structure is not specified, which is a minor gap but not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 explain the parameters, and it does. It specifies 'time_min/time_max ms epoch' and 'calendars_json: [{accountId, calendarId}]', giving units and structure that the schema titles alone do not provide.
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 resource and action: 'Get free/busy blocks for calendars in a time range.' This is a specific verb plus resource and is distinct from calendar-list or event-retrieval siblings, though it does not explicitly name a sibling for comparison.
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 gives an explicit usage trigger: 'Call when checking availability before scheduling.' This is clear context, but it does not mention alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the HTTP method and endpoint, but does not disclose pagination, response format, or any special limitations. 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?
The description is compact: purpose, endpoint shape, parameter meaning, and usage trigger are all included in a few short sentences. The endpoint example is somewhat redundant with the parameter note, but it does not waste much space.
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, single-parameter tool with annotations covering safety, the description provides enough context to select and call it correctly. It could add return-value or pagination details, but these are not essential for a basic list operation.
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 states accounts_json is a required string, with 0% description coverage. The description compensates by explaining it is a 'JSON string array' and showing the expected shape {accounts:[accountId,...]}, which is essential for correct invocation.
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 lists room/resource calendars for accounts, using a specific verb and resource. The phrase 'room/resource' and 'Call when booking rooms' distinguishes it from sibling tools like get_calendars or get_calendar_lists.
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 explicitly provides a usage trigger: 'Call when booking rooms.' It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select this tool 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it is a POST-based read, may be an alias, returns display name/email first, and is not meant for paginated directory access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose and usage decision. The phrase 'Spectral-proven; may be alias' adds noise without helping an agent invoke the tool, so it is not quite a perfect 5.
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?
For a simple tool with one optional parameter and strong annotations, the description gives enough high-level guidance for a basic call, including when to use it and what to display first. However, body_json semantics are unexplained and there is no output schema, leaving ambiguity about request construction and full response shape.
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 coverage is 0%, so the description must compensate, but it only says 'Optional body_json object.' It does not explain what should go inside body_json, what format is expected, or how it affects the request. Worse, it describes body_json as an object while the schema allows string or null, which is potentially misleading.
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 ('Fetch contacts') and resource ('via POST /v2/getContacts'), and distinguishes itself from get_people by positioning this as a quick contact lookup. This makes the tool's purpose unambiguous even among many 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call for quick contact lookup; prefer get_people for paginated directory,' which gives both a when-to-use condition and a named alternative. This is exactly the kind of usage guidance an agent 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?
The description adds useful behavioral context beyond the readOnlyHint annotation by specifying the POST endpoint, epoch time units, the provider default, and the response ordering rule. It complements rather than contradicts the annotations, though it does not mention authorization or rate-limit behavior.
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 tightly structured in three sentences: what it does, when to call it, and key parameter/return details. No word is wasted, and the most decision-relevant information appears first.
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 tool with annotations covering safety, the description covers the core requirements: endpoint, preconditions, parameter semantics, and return-order behavior. It lacks explicit pagination or rate-limit guidance, but this is not a major gap given the tool's simplicity.
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 schema alone does nothing, so the description must carry the weight. It explains that queries_json is a JSON array, notes the default provider, and defines timeMin/timeMax as ms epoch, adding real meaning beyond the lone 'Queries Json' field. The exact internal structure of each query object is still somewhat underspecified.
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 ('Fetch events') and the scope ('in a time window for specific calendars'), making the tool's purpose understandable. It is distinguishable from singular get_event by the plural 'events' and 'time window', though it does not explicitly name a sibling for differentiation.
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 instruction 'Call after you know provider/accountId/calendarId' gives a clear precondition and tells the agent not to invoke this tool before those identifiers are known. It does not explicitly discuss alternatives like search_events or when not to use this tool, so it falls 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 mark the tool destructive/not read-only. The description adds meaningful context beyond that: what exactly gets destroyed (sidebar entry) and what is preserved (the calendar itself). It also discloses the underlying endpoint and mutation shape, giving agents a clearer picture of the side effect.
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 core intent, the endpoint/mutation format, and the destructive scope. 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?
For a simple one-parameter mutation with no output schema, the description covers the key requirements: what to send, how to send it, and what side effect to expect. It lacks explicit return-value or error-behavior info, but that is less critical given the absence of an output schema and the tool's low structural complexity.
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 says mutation_json is a required string with no description, so the description must carry the semantic burden. It does: it explains mutation_json is a JSON object and lists the intended fields (provider, accountId, calendarId). It could more precisely state that mutation_json should be a stringified JSON object, but it still provides substantial guidance beyond the 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?
States a specific verb and resource: "Unsubscribe/remove a calendar from the calendar list." It clearly distinguishes the operation from deleting the underlying calendar by adding "not the calendar itself," which separates it from sibling calendar-destruction 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 implies the tool is for removing a calendar from the user's sidebar/list rather than deleting the calendar itself. However, it does not explicitly name or point to sibling alternatives like insert_calendar_list or update_calendars, so the when-to-use guidance is only implicit.
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 and destructiveHint=false, so the safety profile is known. The description adds the HTTP endpoint and the palette scope, but does not describe response format or any authorization requirements. Given the annotations cover much of the behavioral burden, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, followed by a usage trigger and the endpoint. Every sentence earns its place with no 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, zero-parameter, read-only tool with annotations present, the description provides enough context to select and invoke it correctly. It does not describe the return payload, but the term 'palette' gives a reasonable expectation, and no output schema exists to fill that 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 is complete. The description correctly implies a parameterless call; no parameter explanation is 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?
States a specific verb and resource: 'Fetch calendar color palette.' There is no sibling tool for colors, so it is clearly distinct from the other get_* tools in its family.
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?
Explicitly names when to call the tool: 'when rendering/assigning calendar colors.' It does not mention alternatives, but no close sibling alternatives exist, so this is clear enough.
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 and destructiveHint=false, so the safety profile is clear. The description adds useful context such as identifier alternatives and time-filter options, but it does not disclose return shape, not-found behavior, or any rate-limit/error characteristics. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, information-dense sentences with the most important facts front-loaded. There is no filler or repetition of schema titles.
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-read tool, the description covers the core invocation: endpoint, identifiers, optional filters, when to call it, and precedence. The main gaps are the absence of any return/error expectations and the implicit at-least-one-identifier requirement.
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 schema description coverage at 0%, the description must carry the semantic load. It does: username, alias, and holdShortId are identified as lookup keys, time_min/time_max are called optional and given units in milliseconds, and 'Alias/name first' clarifies precedence. It does not state that at least one identifier is required, so it is not perfect.
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: 'Fetch one Hold (scheduling page) by username, alias, or holdShortId.' It clearly differentiates from get_holds by emphasizing a single Hold, and the parenthetical defines the domain term.
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 explicit guidance: 'Call after get_holds when inspecting availability slots.' This names the natural sibling workflow and intended context. It does not explicitly state when not to use the tool, so it falls just 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 establish that the tool is not read-only and not destructive; the description adds the endpoint and the modifying nature ('Update', POST). It does not describe success/error behavior, partial-update semantics, or side effects, so it adds only modest behavioral context 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?
Three concise sentences with no wasted words. The primary action is first, followed by the endpoint, the parameter requirement, and the sequencing cue.
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 mutation on a known resource, the description covers the purpose, the required payload shape, and the preceding step. It doesn't detail the response or error cases, but no output schema is present and the operation is simple enough that this is a minor 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 input schema only defines a generic hold_json string with 0% description coverage, so the description must carry the meaning. It does: hold_json must contain the id plus fields to change, with alias and timeRanges as examples. Some detail is left to the endpoint's API contract, but the core semantic is conveyed.
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 ('Update an existing Hold') and resource, immediately distinguishing it from get_hold, create_hold, and delete_hold. The endpoint reference and instruction to call after get_hold/get_holds reinforce the targeted behavior 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?
It provides clear context for when to use it: only to modify an existing Hold, and it tells the agent to call get_hold/get_holds first. It doesn't explicitly enumerate when not to use it or name alternatives, but the sibling set and the verb make the boundary clear.
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 not read-only and not destructive; the description adds useful behavioral constraints: eventData must include an id, start/end must be used instead of startTime/endTime, and reminders should default to useDefault:true. This goes beyond what annotations or the bare schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose and precondition, then packs essential technical rules into a few sentences. 'Summary first' is slightly cryptic, but overall the structure is efficient.
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 14-parameter tool with no output schema, the description provides endpoint, required fields, date/time formats, and send_updates options. Ambiguity remains around how the required 'id' maps to the event_id parameter and how optional JSON parameters should be structured, but the core invocation path is well covered.
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 meaningfully compensates by explaining the required eventData fields, the accepted start_json/end_json shapes, and send_updates values. Some optional params like attendees_json, location, and extra_event_json are not detailed, but their names plus the required-field guidance cover most invocation cases.
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 calendar event'), immediately distinguishing it from sibling tools like get_event, update_events, delete_events, and rsvp_event. The endpoint reference adds further clarity.
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?
Explicitly tells the agent when to call it: after confirming calendar and time with the user. It does not list alternatives or exclusions, but the create operation is unambiguous among the available siblings.
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 and openWorldHint, so the description is not responsible for the safety profile. It adds useful behavioral context beyond those annotations by showing the POST endpoint, mentioning the optional userTimeZone, and noting that the summary should be presented 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?
Three tightly packed sentences: purpose, usage condition, endpoint, optional parameter, and output-presentation note. Nothing is wasted, and the most important information is front-loaded in the first 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 single-event fetch with read-only annotations, the description provides sufficient selection and invocation cues. It omits full output-field details, but there is no output schema and the statement 'Fetch one event by id' plus 'Summary first' gives a reasonable picture of the result.
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 0%, so the description must carry the parameter semantics. It does by framing provider/accountId/calendarId/eventId as identifiers one already has, and by explicitly marking userTimeZone as optional. It could explain timezone format or the meaning of each ID further, but the names plus usage context largely compensate.
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 'Fetch one event by id', a specific verb and resource that directly distinguishes this singular lookup from siblings like get_events, search_events, and export_events. It makes the tool's scope unmistakable.
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 'Call when you already have provider/accountId/calendarId/eventId' gives an explicit precondition and clear context for when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the condition strongly implies the boundary.
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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact HTTP call ('POST /v2/getGroupMembers') and request body shape ({accountId, emails:[...]}), so the agent knows precisely what operation occurs. There is no contradiction with the annotations; POST is simply the transport for a read-only resolution.
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 with no filler: purpose, endpoint/payload, and usage condition each earn their place. The scope-setting clause 'Resolve Google group members for attendee expansion' is front-loaded so the agent grasps the tool's role immediately.
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 two-parameter read-only resolver with the safety profile covered by annotations, the description covers purpose, endpoint, payload, and trigger condition. The notable gap is response format — with no output schema, the agent is not told what a resolved group returns (member email list, member objects, errors), which matters for attendee expansion.
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 0%, so the description carries the full burden, and it largely delivers: it specifies that emails_json is a 'JSON array' and maps both parameters into the endpoint payload ({accountId, emails:[...]}). The only residual ambiguity is whether emails_json must be a JSON-encoded string (schema type is string) versus a native array, which is not explicitly stated.
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?
Opens with 'Resolve Google group members for attendee expansion,' a specific verb+resource+purpose that immediately distinguishes this from sibling lookups like get_user, get_people, and get_contacts. The closing clause 'Call when an invitee is a group address' further sharpens the boundary by identifying the exact scenario this tool exists for.
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?
'Call when an invitee is a group address' is an explicit trigger condition, giving the agent clear when-to-use guidance. It does not name alternatives or state when not to use this tool, though the attendee-expansion framing implies the contrast with individual person/contact lookup 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 indicate readOnlyHint=false, so the write nature is expected. The description adds valuable behavioral context by revealing the endpoint POST /v2/rsvpEvent and the constraint that response_status must NOT be needsAction, which is 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?
Three short sentences, each carrying essential information: the action, the trigger condition, the endpoint, the critical constraint, and optional parameters. 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?
For a 7-parameter mutation tool with no output schema, the description covers the most important behavioral details and constraints. It does not explain user_time_zone's purpose, but that parameter is optional and fairly self-explanatory, so the gap is minor.
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 compensates for key parameters: response_status allowed values, the required non-needsAction constraint, optional comment behavior, and counter_proposal_json's {start,end} shape. Other parameters like account_id, calendar_id, and event_id are self-evident from their schema titles.
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: 'RSVP to an event invite', then lists the allowed response statuses (accepted|declined|tentative). This clearly distinguishes it from sibling event tools like create_event, update_events, or get_event.
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 explicitly states when to call: 'Call when the user wants to respond to an invitation.' It does not mention alternatives or exclusions, but the trigger condition is clear and sufficient for most agents.
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 readOnly=false and destructive=false, and the description adds the PATCH semantics plus a batch mutation array, signaling multiple calendars can be updated in one call. It doesn't cover permissions or reversibility, but for a non-destructive metadata patch the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but brief, front-loading the action and including only the endpoint, payload shape, and usage trigger. The phrase 'Summary first' is cryptic and adds confusion, slightly marring an otherwise efficient structure.
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 mutation tool with no output schema, the description provides the HTTP endpoint, body structure, and parameter format. The main gap is whether mutations_json should be passed as a stringified JSON array or a raw array; the schema type 'string' implies stringification, but the description doesn't explicitly state it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden for the lone mutations_json parameter. It explicitly defines it as a JSON array and specifies the mutation object fields (provider, accountId, calendarId, calendarData, colorRgbFormat?, variant?), which is far 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?
States a specific action ('Patch') on a specific resource ('calendar metadata') with concrete examples (summary, color, selected). The HTTP endpoint further disambiguates it from sibling tools like update_events or update_holds, making the tool's role immediately recognizable.
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 an explicit trigger for use: 'Call when renaming/recoloring calendars.' It doesn't name alternatives or conditions to avoid, but the usage context is clear enough for an agent to select it appropriately among siblings.
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 a write operation (readOnlyHint=false). The description adds meaningful behavioral context: the POST endpoint, patch semantics, and sendUpdates notification control. This goes beyond the annotations and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but organized, leading with the action and trigger, then presenting the endpoint shape and parameter details. Every sentence contributes useful information, though the inline JSON example makes it a bit sprawling.
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 request shape, mutation semantics, and notification options, which is enough to invoke the tool correctly. The absence of return-value information is a minor gap, but with openWorldHint and no output schema, the agent mainly needs invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates thoroughly. It explains that mutations_json is a JSON array, lists the mutation object fields, specifies patch semantics, and enumerates sendUpdates values. This gives the agent everything needed to construct the 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 and resource: 'Update one or more existing events.' The 'Call when changing time/title/details' reinforces the tool's purpose and distinguishes it from create_event and delete_events 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?
Explicitly states when to call: when changing time/title/details. It also gives operational guidance like patching eventData and keeping summary visible, but it does not explicitly name alternative tools or define when not to use it, so it falls just 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?
Beyond the annotations, the description reveals important behavioral details: the etag-based optimistic concurrency requirement and the 412 stale response. It also shows the endpoint and payload shape. There is 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?
The description is three short, information-dense sentences. It front-loads the purpose, then gives the precondition/error behavior, then the payload format. No filler or redundant restatement.
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 update tool with no output schema, the description covers the essential call contract: what to update, the required etag, the stale-error behavior, and the payload format. It does not describe the response, but that is a minor gap given the tool's simplicity.
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 0%, so the description carries the burden. It explains user_preferences_json as a full/partial prefs object including etag and shows the enclosing POST body shape, which is enough for an agent to construct the argument.
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: 'Update Calendar user preferences.' It also clearly distinguishes the update action from the getter sibling get_user_preferences and adds the critical prerequisite of using an etag from that getter.
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 explicitly states when to call the tool: only with an etag from get_user_preferences, and notes the 412 failure on a stale etag. It does not explicitly list when-not-to-use alternatives, but no direct update competitor exists among the sibling 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 declare readOnlyHint=true and destructiveHint=false, and the description is consistent with those. It adds useful behavioral context beyond the annotations: the POST endpoint, the queries array shape (provider, accountId, optional query), and a return-order note ('Summary first'). 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?
Four short, information-dense sentences front-load the purpose, then cover endpoint, parameter format, alternative routing, and output style. There is no filler or repetition.
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 one required parameter, read-only annotations, and no output schema, the description provides enough to select and invoke the tool: purpose, endpoint, input format, an alternative, and a hint about response order. It could specify exact response fields and error behavior, but it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter description (0% coverage), leaving the description as the sole explanation. It clarifies that queries_json is a JSON array and shows its element structure via the endpoint example, fully compensating for the bare 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 states a specific verb and resource: 'Fetch calendar metadata (colors, access role, timeZone) for accounts.' It clearly differentiates from get_calendar_lists by noting that get_calendar_lists is preferable for the sidebar list, helping an agent select among 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?
It explicitly says 'Prefer get_calendar_lists for the sidebar list,' giving a clear when-not-to-use condition. It does not contrast with all other siblings like get_colors or get_synchronized_calendars, but the context of fetching calendar metadata for accounts is clear enough.
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, openWorldHint=true, and destructiveHint=false, covering safety. The description adds useful behavioral context beyond annotations: it reveals the endpoint ('POST /v2/getNotionSessionUsers {}') and specifies output ordering ('Display name/email first'), which helps the agent anticipate the response format.
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 deliver purpose, usage trigger, and response behavior with no filler. The most important information is front-loaded, and every sentence contributes to correct invocation.
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 tool, the description is complete: it states the resource being listed, the invocation context, the endpoint, and the display format. No output schema exists, but the description compensates with the 'Display name/email first' guidance.
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 is no parameter ambiguity. Per the baseline rule for tools with no parameters, a score of 4 is appropriate; the description doesn't need to add parameter semantics that don't exist.
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 begins with a specific verb and resource: 'List Notion session users tied to this Calendar session.' This clearly identifies the tool's function and scope, distinguishing it from the many other get_* sibling tools by its Notion-specific purpose.
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 explicitly says 'Call when bridging Calendar ↔ Notion identity,' which gives a clear trigger condition for use. It does not explicitly mention when not to use it or name alternatives, but the guidance is direct and sufficient for this niche 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 include destructiveHint=true and readOnlyHint=false, and the description reinforces 'Destructive'. It adds useful behavioral context beyond the annotations by requiring confirmation and specifying sendUpdates side-effect options (all|none|externalOnly), which is valuable for an agent deciding whether to invoke 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?
The description is compact and dense, front-loading the action and confirmation warning before providing the request shape and option values. Every clause adds operational value and 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 mutation tool with strong annotations and no output schema, the description covers the call condition, payload structure, parameter type, and important option values. An agent has sufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines mutations_json as a string with no description, but the description compensates by clarifying 'mutations_json: JSON array' and specifying the mutation object fields and sendUpdates enum. This gives the agent enough meaning to construct the parameter correctly despite 0% schema description coverage.
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 'Delete one or more events', a specific verb and resource, and is reinforced by the POST /v2/deleteEvents endpoint. It is clearly distinct from sibling tools like update_events or search_events, so an agent can identify what this tool does 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 an explicit condition: 'Call only after confirming which event(s)'. This provides clear when-to-use context, though it does not name alternatives or state when not to use the tool beyond the confirmation requirement.
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 destructiveHint=false, covering the mutation-safety profile. The description adds value by stating the return payload ('profile + linked accounts') and the authentication prerequisite ('Session JWT required'), which are not derivable from annotations or the empty 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?
The description is three tightly packed sentences with no filler. The most important instruction ('Call first') is front-loaded, followed by purpose, endpoint, return summary, ordering guidance, and auth requirement—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 zero-parameter read-only tool, the description is nearly complete: it explains what the call returns, when to call it, and a key prerequisite. The only slight gap is that 'profile + linked accounts (title/email first)' is not a precise schema, and with no output schema this is partly ambiguous—but it is sufficient for a first-step discovery 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?
The tool has zero parameters and the schema has no properties, so there is nothing for the description to illuminate. The mention of 'POST /v2/getUser {}' confirms a parameterless call, satisfying the baseline for a 0-parameter tool.
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: 'learn who is signed in and which calendar accounts exist.' It clearly identifies the tool's role as a user-info retrieval call and distinguishes it from sibling tools like get_calendar_lists or get_events by framing it as the prerequisite identity/account discovery step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call first' and 'Use before get_calendar_lists / get_events,' giving concrete sequential guidance. It also mentions the session JWT requirement, which is a necessary invocation condition. This leaves no ambiguity about when or why 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 read-only and non-destructive behavior. The description adds valuable behavioral context beyond that: the endpoint, the failure mode without valid sync tokens, and the expected payload shape including metadata:{caller}. 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?
The description is compact and front-loaded: purpose, endpoint/payload, failure condition, and sibling routing are all covered without filler. Every sentence adds information, and the parameter mapping at the end is a useful quick reference.
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 read-only two-parameter advanced sync tool, the description covers invocation details, preconditions, and routing. The lack of an explicit return-value description is a minor gap since no output schema is provided, but it does not block 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 description coverage is 0%, so the description must compensate. It identifies sync_tokens_json and metadata_json, marks metadata as optional, and maps them to the endpoint body. It could specify the token JSON format more precisely, but the provided semantics are sufficient for basic invocation.
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 resource and action: 'Drive incremental calendar sync with sync tokens,' and names the exact endpoint and payload. It also differentiates itself from get_events, so an agent can identify when this tool is the intended one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: this is for advanced use, normal reads should prefer get_events, and calls without valid prior sync tokens often fail with 400. This gives a strong when-to-use and when-not-to-use signal relative to the large sibling list.
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 readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by disclosing that results are scoped to the signed-in user, that the call maps to POST /v2/getHolds, and that returned data is oriented around aliases/ids rather than raw ids.
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 adding distinct value: what the tool does, when to use it, and how to use the results. 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.
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 list tool with readOnly/destructive annotations and no output schema, the description is sufficiently complete. It states the scope, the purpose of the returned data, and the relationship to downstream tools.
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?
There are zero parameters, so the baseline is 4. The description also confirms the request body is empty ('{}'), which removes any ambiguity about calling conventions.
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') with a clear resource ('scheduling Holds (booking pages)') and scope ('for the signed-in user'). It also references sibling tools get_hold/create_hold, helping an agent distinguish this list operation from related action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call this tool: when hold aliases/ids are needed before get_hold or create_hold. It also gives practical guidance ('Name/alias first, never lead with id'), which clarifies usage conventions beyond just listing holds.
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 destructiveHint=false. The description adds useful behavioral context by naming what data is read (working hours, defaults, etag) and by explaining the etag's role in a subsequent update. It does not describe response shape or error behavior, but this is acceptable for a simple no-argument read with strong 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 three short sentences with no filler. It front-loads the purpose, then gives the usage relationship, and ends with the endpoint. Every sentence 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 tool with safety annotations already provided, the description is complete. It identifies the resource, the relevant data fields, the dependency on update_user_preferences, and the endpoint. An agent has enough to select and invoke the tool 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?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description reinforces the empty call via 'POST /v2/getUserPreferences {}', but there are no parameter semantics to explain beyond what the schema already 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 starts with a specific verb 'Read' and clearly identifies the resource: 'Calendar user preferences'. It also lists representative contents (working hours, defaults, etag), which distinguishes it from sibling tools like get_user, get_calendars, or update_user_preferences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Call before update_user_preferences', and explains that the etag is required for the force check. This gives an agent a concrete workflow and removes ambiguity about the intended call order.
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:

[![notion-calendar-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/felipeorlando/notion-calendar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/felipeorlando/notion-calendar-mcp)

Score Badge

Copy to your README.md:

[![notion-calendar-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/felipeorlando/notion-calendar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/felipeorlando/notion-calendar-mcp)

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/felipeorlando/notion-calendar-mcp'

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