Agent-first field workforce scheduling. Your agent schedules crews, verifies GPS punches, collects forms, and exports timesheets. No dashboard. Keys zsc_. $5 activation credited. Worker invite $0.25. No seats. Docs: https://www.zensched.com/docs/quickstart/ Pricing: https://www.zensched.com/pricing/ Android: https://play.google.com/store/apps/details?id=com.zensched.app iOS TestFlight beta: https://testflight.apple.com/join/Wp51m5Yq
Average 4.4/5 across 11 of 11 tools scored. Lowest: 3.8/5.
The account tools are distinct flow steps (start/verify for signup, signin, recover) plus a status check and key usage, so they're largely unambiguous. However, the two start/verify pairs could be confused, and feedback_submit/zensched_guide are unrelated to account management, though their purposes are clear from descriptions.
The majority follow an 'account_' prefix with verb_style suffixes (e.g., account_signin_start). feedback_submit and zensched_guide break the pattern, but they are distinct actions and the naming is still readable and predictable overall.
11 tools is a reasonable number for an authentication-focused server, but the server is supposed to be for scheduling. With 8 of 11 tools being account/auth, the count feels heavy on setup and light on actual domain operations.
The tool surface is almost entirely authentication and account management, with no tools for scheduling core resources like locations, workers, shifts, or timesheets—despite the guide mentioning these as the intended workflow. The server would be useless for actual scheduling tasks.
account_auth_statusACheck whether this connector is signed in as a ZenSched org. Call this before account_get in a new session. Unauthenticated; never errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/destructiveHint annotations, the description discloses that the tool is 'Unauthenticated' and 'never errors,' which are meaningful behavioral traits an agent needs to know. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. The core behavior is front-loaded, followed by usage timing and key behavioral guarantees. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema, safety annotations, and a clear instruction on when to call it, the description is complete for an agent to select and invoke it correctly. The only minor gap is referencing 'account_get' without it appearing in the sibling list, but this does not impair invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema is empty, so the description does not need to explain parameter semantics. The no-parameter case is already fully represented by the schema, earning the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a clear resource ('whether this connector is signed in as a ZenSched org'). It clearly identifies the tool's role as an auth status check, distinguishing it from sibling sign-in/recovery flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Call this before account_get in a new session.' This gives concrete context, though it does not explicitly enumerate alternatives or when not to use it beyond that single instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_createAInspectCreate a ZenSched org without email (MCP-only agents). No OTP — returns org_id + zsc_ key immediately. Store the key securely. To attach a contact email later for human recovery, call account_set_contact. Rate-limited aggressively.
| Name | Required | Description | Default |
|---|---|---|---|
| org_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It adds that no OTP is involved, returns org_id + zsc_ key immediately, requires secure key storage, and is rate-limited. Minor gaps remain around idempotency or retry behavior, but they are not critical for a one-parameter create.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, each adds distinct information: core purpose, response behavior, storage warning, follow-up path, and rate limit. The essential create action is front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers purpose, return value, key security, and a follow-up route. It is slightly incomplete because org_name semantics are left to the schema title, and the referenced account_set_contact tool is not present in the provided sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for org_name semantics, but it never mentions org_name or gives format, length, or uniqueness guidance. The only meaning comes from the schema title 'Org Name', and the description adds no parameter-specific value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Create a ZenSched org') and the main distinguishing constraint 'without email (MCP-only agents)', separating it from email-based signup flows. The no-OTP detail further clarifies what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says this is for MCP-only agents and points to an alternative when a contact email is needed later: account_set_contact. It also warns that the tool is aggressively rate-limited, giving clear operational context for when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_recover_startAInspectLost API key (step 1 of 2): sends a verification code to the org owner email. Then call account_recover_verify. Prefer account_signin_start if you only need to reconnect — Recover revokes ALL keys.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it sends a code to a specific email, is part of a two-step flow, and warns that recovery revokes ALL keys. The warning is correctly framed as a property of the recovery process, not necessarily of this immediate call, so it does not contradict destructiveHint=false. The openWorldHint=true annotation is consistent with the email-sending 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver purpose, sequencing, an alternative, and a critical side-effect warning. Every clause earns its place, and the most identifying information ('Lost API key (step 1 of 2)') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what an agent needs to decide whether to use this tool, how to invoke it, and what to do next. The output schema exists, so return-value details do not need to be in the description. The routing to account_recover_verify and account_signin_start closes the main contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does by clarifying that the email parameter should be the 'org owner email', not just any email. It could add detail about expected format or verification-code delivery, but for a single required parameter this is sufficient semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('sends a verification code') and a specific resource ('to the org owner email'), and explicitly distinguishes this tool from account_signin_start. The 'step 1 of 2' framing makes its role in the recovery flow unambiguous, so an agent can identify it without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit selection guidance: use this when the API key is lost and follow it with account_recover_verify. It also names the alternative (account_signin_start) and the condition that makes that alternative preferable ('if you only need to reconnect'). No inference is needed to decide when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_recover_verifyALost API key (step 2 of 2): verify the code. Issues a fresh key and revokes ALL previous keys.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already include destructiveHint=true, but the description adds crucial specifics: it 'revokes ALL previous keys' and 'issues a fresh key'. This goes beyond the generic annotation and warns the agent about a significant side effect, though it does not describe failure behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence that front-loads the workflow context and then states the action and its consequences. Every phrase earns its place and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential workflow context and destructive outcome, and output schema coverage means return values need not be explained. However, the parameters are underspecified—especially 'email'—so the agent must infer too much about what values to provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds almost no parameter meaning. It refers to 'the code' but does not explain what the code is, where it comes from, or how it relates to the email parameter; the 'email' field is never mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'verify the code' in the 'Lost API key' recovery flow, and clearly distinguishes this as 'step 2 of 2' from the prior recovery step. It also names the concrete outcome—issuing a fresh key and revoking previous keys—so an agent can identify the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Lost API key (step 2 of 2)' gives clear sequential context: use this after the recovery start step, not before. It does not explicitly name alternatives or say when not to use it, but the step framing makes the intended placement obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_signin_startAInspectReconnect an existing org without rotating keys (step 1 of 2): emails a 6-digit code to the owner. Then account_signin_verify. Prefer this over Recover.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, openWorldHint=true) already signal side effects; the description adds that an email is sent with a code, which is consistent. It does not mention code expiry or resend limits, but with annotations covering the safety profile, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: purpose, step, and alternative are all covered. The most critical information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, this description covers the purpose, the two-step flow, and the preferred alternative. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It clarifies that the email parameter is the owner's email for an existing org, which is essential context the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action: 'Reconnect an existing org without rotating keys' and clarifies it is step 1 of 2, sending a 6-digit code. It also distinguishes itself from the 'Recover' alternative, making its role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer this over Recover' and directs to account_signin_verify as the next step, giving a clear preference and flow. This is as direct as the calibration example and tells the agent when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_signin_verifyAInspectReconnect an existing org without rotating keys (step 2 of 2): verify the emailed code. Call this after account_signin_start. If later org tools fail, call account_signin_verify again or account_use_key.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint, openWorldHint, and destructiveHint; the description adds useful behavioral context: this step does not rotate keys, it verifies an emailed code, and it can be retried. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the core purpose, then add sequencing and fallback guidance without wasted words. Every clause contributes to correct tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter verification step with an output schema provided, the description covers the workflow position, retry behavior, and alternative tool. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description partially compensates by indicating the code is emailed and the flow reconnects an existing org. However, it does not explicitly name or explain the email and code parameters beyond what the schema titles themselves imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('verify the emailed code'), a clear resource ('an existing org'), and positions it as step 2 of 2 in a reconnect flow. It also distinguishes itself from account_signin_start and account_use_key by naming the workflow step and alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call after account_signin_start, and provides fallback guidance ('call account_signin_verify again or account_use_key') if later org tools fail. This gives the agent concrete sequencing and alternative-routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_signup_startAInspectCreate a ZenSched org (step 1 of 2): sends a 6-digit verification code to the email. Unauthenticated; rate-limited. Then call account_signup_verify.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| org_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond annotations: it sends a 6-digit code to the email, is unauthenticated, and is rate-limited. It also clarifies the two-step nature of the process. This gives the agent a clear picture of what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose, state the key behavioral constraints, and point to the next step. Every sentence earns its place with no redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter signup step, the description covers the essential context: auth status, rate limiting, verification code behavior, and the follow-up call. An output schema exists, so return-value explanations are not required. Minor missing detail is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'email' as the recipient of the code. It does not explain the meaning or expected format of org_name or add semantics beyond the parameter names. With no schema descriptions, the tool definition should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create a ZenSched org'), marks it as 'step 1 of 2', and identifies the distinct resource (org creation via email verification). It also names the subsequent sibling, account_signup_verify, making it easy to distinguish this from the rest of the signup flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: this is for unauthenticated org creation and is rate-limited. It explicitly says to call account_signup_verify next, guiding workflow. It does not explicitly state when not to use it (e.g., existing users should sign in), but the context is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_signup_verifyAInspectCreate a ZenSched org (step 2 of 2): verify the emailed code. Returns org_id and your zsc_ API key (shown once). Claude.ai must then Connect → Sign in with the same email — do not keep calling org tools until Connect succeeds.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false, so the description carries the burden of behavioral disclosure. It reveals that the API key is shown only once, that the tool is part of org creation, and that external Connect action is required. This is valuable context, though it does not mention failure modes (e.g., wrong code) or idempotency. Since it covers the key behavioral quirks without contradicting annotations, a 4 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff. The first sentence packs purpose, step, and return value; the second delivers a crucial workflow warning. The most important usage guidance is placed at the end but is clearly emphasized. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, external dependency), the description covers the call sequence, parameter meaning, return values (org_id and API key), and the mandatory next step. The presence of an output schema means return details need not be fully spelled out. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. 'Verify the emailed code' unambiguously identifies the code parameter and implies email is the address that received it. It does not specify that the email must match the one used in step 1, but that is reasonably inferable from the flow. This adds meaning beyond the bare schema, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (verify the emailed code), the resource (ZenSched org creation) and marks it as step 2 of 2, clearly differentiating it from the sibling account_signup_start and sign-in tools. It also names the returned values (org_id and API key), leaving no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly places the tool in a two-step flow ('step 2 of 2') and gives a critical post-condition: 'Claude.ai must then Connect → Sign in with the same email — do not keep calling org tools until Connect succeeds.' This tells the agent exactly when it should be used, what must follow, and what to avoid, effectively routing the workflow away from siblings like account_signin_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
account_use_keyAInspectAuthenticate this connector with an existing zsc_ API key. Prefer this when the key is already in the conversation. If the connector shows Connected but org tools fail, call this or account_signin_start — do not look for a Connect button.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false, so the mutation safety profile is defined. The description adds useful context about when the tool is needed, such as the 'Connected but org tools fail' scenario, but it does not disclose details like whether the API key is stored, overwritten, or how success/failure is surfaced. With annotations present, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The core purpose is front-loaded, and each subsequent sentence adds distinct usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, output schema present, basic annotations), the description covers the essential invocation context: what to authenticate with, when to prefer it, and when to use an alternative. It could go slightly deeper on what happens after authentication, but nothing critical is missing for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only provides the bare title 'Api Key.' The description compensates by specifying the key type ('existing zsc_ API key') and the context ('already in the conversation'), which adds real meaning to the parameter. For a single simple string parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb and resource: 'Authenticate this connector with an existing zsc_ API key.' It clearly identifies the tool's action and object, and distinguishes it from account_signin_start by the condition 'when the key is already in the conversation.' This is precise and differentiated from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Prefer this when the key is already in the conversation.' It also provides a troubleshooting trigger ('Connected but org tools fail') and names an alternative ('call this or account_signin_start'), plus a clear exclusion ('do not look for a Connect button'). This is strong, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
feedback_submitAInspectFile a grievance or product recommendation. Free. Works even before you have an account. Categories: bug, friction, missing_capability, docs, billing, feature, other. Severity: low, medium, high, blocker. Include related_tool and paste error text in context when reporting a bug. A human reads every submission.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| title | Yes | ||
| context | No | ||
| category | No | other | |
| severity | No | medium | |
| related_tool | No | ||
| idempotency_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it is free, works without an account, and 'a human reads every submission.' It does not contradict the readOnlyHint=false or destructiveHint=false annotations, and it gives enough operational context for a feedback tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and every sentence adds useful information. It packs categories, severity values, usage guidance, and a behavioral note without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a feedback submission tool, the description covers purpose, allowed values, account requirements, cost, and human review. The output schema covers return values, so that is not a gap. The only missing contextual element is guidance on idempotency_key and duplicate submissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden of explaining parameters, and it does well for category, severity, related_tool, and context. However, idempotency_key is not explained and title/body receive no explicit guidance, leaving minor gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'File a grievance or product recommendation' — and immediately distinguishes the tool from the account-management siblings. It also enumerates categories and severity levels, making 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: it works before account creation, is free, and provides field-specific guidance for bug reports. It does not explicitly state when not to use it or name alternatives, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zensched_guideASTART HERE. The ZenSched agent guide: how to Connect (Claude.ai) or use a zsc_ key, then fund → locations → workers → shifts → timesheets. Also covers the suggestion box (feedback_submit).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety traits. It adds useful context about the guide's contents (connection, workflow, feedback), but doesn't describe the format of the returned guidance or any pagination/truncation behavior. This is adequate but not rich behavioral disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with 'START HERE' before the core details. The arrow flow efficiently communicates the sequence of steps, and every sentence adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter guide tool with an output schema present, the description covers everything an agent needs: what the guide is, its content scope, and the order of operations. It also mentions the feedback_submit topic to prevent an agent from overlooking that sibling. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema already confirms this with 100% coverage. The baseline for 0 params is 4 because there is nothing to clarify about arguments. The description doesn't need to add parameter semantics since none exist, and it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description unmistakably states this is the ZenSched agent guide, with 'START HERE' signaling its role as the entry point. It specifies the resource (guide) and outlines the covered workflow (fund → locations → workers → shifts → timesheets), clearly distinguishing it from all sibling action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'START HERE' explicitly tells the agent when to use this tool: at the beginning of a session. It also references the connection methods (Claude.ai or zsc_ key) and names feedback_submit as another covered topic, providing clear context for routing. It lacks explicit 'when not to use' phrasing, but the positioning is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
