This server provides MCP tools to automate a GetCourse account via a logged-in browser session (CDP), with no official API required. Capabilities include:
Session & User Management: Check login status (gc_status); find users by email (gc_find_user); get a comprehensive profile/group/order summary (gc_user_summary); and update profile fields like name, phone, city, comment (gc_update_user).
Group & Access Management: List training access groups (gc_list_training_groups); list groups a user belongs to (gc_list_user_groups); check membership instantly (gc_check_membership); add users to groups (creating new users if needed) via import (gc_add_user_to_groups) or via profile card (gc_add_to_groups); remove from groups (gc_remove_from_groups); copy access from one user to another (gc_copy_access).
Order & Payment Management: Search sales offers (gc_find_offers); list user orders (gc_find_orders); create orders to grant access, with optional 0₽ auto-payment for instant access (gc_create_order); complete payment for orders (gc_pay_order); change order status (gc_set_order_status); process refunds (gc_refund_order).
Mailing Categories: List, add users to, and remove users from mailing categories (gc_list_mailing_categories, gc_add_to_mailing_category, gc_remove_from_mailing_category).
General Features: Most write operations support a dryRun mode to preview changes before committing. All actions leverage your existing CDP browser session, ensuring security without storing credentials.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@getcourse-mcp find user by email student@example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Automate a GetCourse account from an AI agent — grant lesson/training access, manage users and groups — with no official API.
English · Русский
GetCourse has no public API for the things admins do every day — opening a lesson for a student, adding someone to a training, moving users between groups. Those actions live only in the admin UI.
getcourse-mcp exposes them as MCP tools. It drives a browser you're already logged into over CDP, so it reuses your real session cookie and CSRF token — no scraping of passwords, no fragile API keys. An AI agent (Claude, etc.) can then find a user, inspect their groups and grant access in one turn.
🔑 Uses your live session — connects over CDP to a logged-in Chromium/Yandex browser
👥 Access by groups — the GetCourse model: training/lesson access = group membership
🧩 5 focused tools — status, find user, list groups, check membership, add to groups
🪶 TypeScript, ESM — thin, strict, MIT, no account secrets in the repo
Related MCP server: Coursera MCP
Access to a training (and its lessons) is granted by group membership. "Full access" to a course often means membership in a Module 1 group plus a group that starts the drip schedule (module 1 now, the rest on a timer). To "give access like another student", read their groups and reproduce them:
gc_find_user # student@example.com → id, name
gc_check_membership # which of these groups is student X in?
gc_add_user_to_groups # add student Y to the same groupsSome offers (franchises, "только купившие" trainings) deliver access only from a completed purchase — group membership grants nothing there. Grant it in one call:
gc_find_offers {"query":"Трафик Формула"} # → offer id, e.g. 6510356
gc_create_order {"email":"user@x.ru","offerIds":["6510356"],"complete":true}
# creates the order AND completes a 0₽ payment → access is live immediately⚠️ A priced deal left in «Новый» delivers NO access — it must be paid. There is no «Оплачен» item in the status dropdown; completion is payment-driven. complete:true (or a later gc_pay_order {"dealId":"…"}) registers a 0₽ received payment → deal → «Завершён» → access granted. Use complete only for 0₽/comp offers.
A 0₽ order has nothing to pay, so GetCourse flips it «Новый → Завершен» on creation by itself; complete:true then detects the finished deal and touches nothing. Purchase-based access does not appear in the user's groups — that's by design, not a bug. Verify it on /teach/control/stat/user/id/<userId> (Training / Lesson access), which reflects the grant immediately.
A Chromium-based browser (Chrome / Yandex) launched with a debug port on a separate profile, logged into your account:
browser.exe --remote-debugging-port=9222 --user-data-dir=C:\gc-cdp-profileNode ≥ 18.
npm install
cp .env.example .env # set GETCOURSE_BASE_URL (and GETCOURSE_CDP_URL if not :9222)
npm run buildRegister it with your MCP client (see .mcp.json.example):
{
"mcpServers": {
"getcourse": {
"command": "node",
"args": ["dist/index.js"],
"env": { "GETCOURSE_BASE_URL": "https://your-account.getcourse.ru" }
}
}
}Tool | Purpose |
| Check the CDP browser session actually has admin rights (not merely that a session exists). Reports the "logged in as a student" case separately. |
| Find a user by email → id, name, type, status. |
| Access groups of a training (id + name). |
| Groups a user belongs to (id + name). |
| Is a user in the given groups? (instant, via the user list) |
| Add an existing user to groups via the card (preserves other groups). |
| Remove a user from groups = revoke access. |
| Add via the bulk import (creates the user if new) = grant access. |
| Give a user the same groups as a reference student. |
| Edit card fields (first/last name, phone, city, comment). Email is out of scope. |
| Search sales offers by name → id + price + actuality. |
| List a user's orders (dealId + status). |
| Create an order = grant access via a purchase (the only way for "buyers-only" trainings, where groups don't grant access). Reports the created deal's id and status; a priced deal in «Новый» means no access until paid, |
| Complete a deal by registering a received payment ( |
| Change a deal's status (e.g. cancel a duplicate: |
| File a money refund for an order via the GetCourse payment module (real money back to the buyer's card). Only for payments processed by the platform; VAT must mirror the original receipt. |
| One call: profile + groups + orders for a user. |
| List mailing categories (tag-like segmentation) — id + name. |
| Add a user to a mailing category. |
| Remove a user from a mailing category. |
Run the MCP server over stdio, or call a tool directly for scripting:
node dist/index.js # MCP (stdio)
npx tsx src/run.ts gc_find_user '{"email":"user@example.com"}'
# → Found: Jane Doe | user@example.com | student | active | id: 100200300
npx tsx src/run.ts gc_add_user_to_groups \
'{"email":"user@example.com","groupIds":["100001","100002"]}'
# → OK [done] import submitted
npx tsx src/run.ts gc_check_membership \
'{"email":"user@example.com","groups":[{"id":"100001","name":"Module 1"}]}'
# → ✅ Module 1 (100001)Granting access (gc_add_user_to_groups) uses the bulk Add users form (/pl/user/user/import?type=text): email + selected groups. For an existing user the "overwrite on match" flag is required (overwriteExisting, default true), otherwise the groups are not applied — the import carries only the email, so no profile data is touched.
A direct mass action exists (POST /pl/logic/operation/prepare?operationType=user_addtogroup), but in the current UI it is a selection-builder wizard — a candidate to wire up as an alternative path.
Membership is checked through the user list filtered by a user_ingrouprule rule (params.value.selected_id), which reflects membership immediately (the training student list mirrors access asynchronously and is not reliable for verification).
Writes never trust their own exit code. A single-step operation can throw after the mutation landed, so gc_create_order snapshots the user's deals first and reports the deal that actually appeared — which also removes the "newest deal must be ours" guess.
The session check tests rights, not the mere presence of a session. gc_status probes the admin user list (/pl/user/user) — the endpoint gc_find_user/resolveUserId depend on. It used to check /teach/control, which renders for students too: a student session reported "✅ logged in" and every later read silently ran as that student. The "denied" signal is anchored on GetCourse's own error-page wording so stray list content can't lock an admin out.
__name shim. page.evaluate callbacks are serialized and run inside the page. esbuild (what tsx runs on) rewrites named inner functions into __name(...) calls, which do not exist there — hence ReferenceError: __name is not defined under tsx src/*.ts while the compiled dist/*.js works. Every navigation installs a no-op shim (ensureEvalShim), so both entry points behave the same. If you drive page.goto yourself, call ensureEvalShim(page) after it.
Contributions are welcome — open an issue or a PR. Good first ideas:
direct user_addtogroup mass action instead of the import form
a "copy all groups from one student to another" tool
revoking access (gc_remove_user_from_groups)
exporting students; test coverage
Fork and branch: git checkout -b feature/my-change
npm install, make changes; npm run build and npx tsc --noEmit must pass
Never commit secrets (cookies/passwords/.env) or real account data
Open a PR describing what and why
Secrets (cookies/passwords) live only in the browser and your environment — never in the repo. .env and a local .mcp.json are git-ignored.
MIT
Добавить существующего пользователя в группы через карточку (чисто, без импорта; сохраняет остальные группы). dryRun — предпросмотр.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email существующего пользователя. | ||
| dryRun | No | Показать изменение без сохранения. | |
| groupIds | Yes | ID групп, в которые добавить (= выдать доступ). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is clean (preserves other groups) and offers a dry-run preview. However, without annotations, it lacks details on failure modes, permissions, or side effects beyond what is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. Every word earns its place, and the key points are 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 simple 3-parameter tool without output schema, the description adequately covers the core action and the dryRun feature. However, it lacks information on return behavior, error conditions, and fails to differentiate from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no new information beyond the parameter descriptions in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an existing user to groups, preserving other groups and without import. However, it does not differentiate from the similarly named sibling 'gc_add_user_to_groups', which may cause confusion.
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 no explicit guidance on when to use this tool versus alternatives. It mentions dryRun for preview but no when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Добавить пользователя в категорию рассылок (по categoryId из gc_list_mailing_categories).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. | ||
| categoryId | Yes | ID категории рассылок (см. gc_list_mailing_categories). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is an add operation but does not mention side effects, permissions, duplicate handling, or whether the user must exist. Basic transparency but not detailed.
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?
Single, efficient sentence that conveys the core purpose and a key prerequisite. No unnecessary 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 simple two-parameter tool with no output schema, the description is largely complete. It covers what it does and where to get the needed IDs. Could mention if the email must correspond to an existing user, but not essential.
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 100% with adequate parameter descriptions. The tool description adds value by referencing gc_list_mailing_categories for the categoryId, but does not provide new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a user' and the resource 'mailing category', with a reference to gc_list_mailing_categories for obtaining the categoryId. It distinguishes from sibling tools like gc_remove_from_mailing_category and gc_add_to_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing gc_list_mailing_categories but does not explicitly state when to use this tool versus alternatives or provide any exclusions. No guidance on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Добавить пользователя в группы через импорт (создаёт нового при отсутствии) = выдать доступ. dryRun — предпросмотр.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя (существующий или новый). | ||
| dryRun | No | Дойти до предпросмотра без подтверждения (по умолчанию false). | |
| groupIds | Yes | ID групп, в которые добавить. | |
| sendInvitation | No | Отправлять письмо-приглашение (по умолчанию false). | |
| overwriteExisting | No | Ставить флаг «перезаписать при совпадении» — нужен, чтобы группы применились к существующему юзеру (по умолчанию true; импорт несёт только email, данные не теряются). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the creation aspect and dry-run preview, but omits details like additive vs overwrite behavior, permission requirements, and side effects. The schema fills some gaps (e.g., overwriteExisting), but the description does not integrate them.
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 very concise (one sentence plus a fragment). It front-loads the primary action. However, it could benefit from a slightly more structured format to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 2 required, and no output schema, the description is too minimal. It fails to explain the overall behavior, such as whether the operation is additive or replaces groups, permission requirements, or the effect on existing memberships. The schema helps, but the description lacks necessary context.
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 100%, so the baseline is 3. The description only adds value for the 'dryRun' parameter, comparing it to preview. Other parameters rely solely on schema descriptions, which are adequate but not enhanced by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add user to groups), the resource (user and groups), and the special behavior of creating a new user if absent. It distinguishes from sibling tools like 'gc_add_to_groups' by highlighting the import/creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when a user might not exist, mentioning 'creates new at absence'. However, it does not explicitly state when to use this vs alternatives like 'gc_add_to_groups', nor does it provide when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Проверить, состоит ли пользователь (по email) в указанных группах (по списку пользователей — мгновенно).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. | ||
| groups | Yes | Группы для проверки: [{id, name?}]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a non-destructive check operation, but fails to mention return value format, authentication requirements, error handling, or rate limits. The term 'мгновенно' adds slight context, but overall transparency is average.
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?
A single sentence that conveys the core purpose, though the phrase 'по списку пользователей' may be slightly confusing (should be 'групп'). Still, it is concise and front-loaded with the action.
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 tool has no output schema, so the description should clarify what the agent can expect as a result (e.g., boolean, membership list). This is missing entirely. Additionally, it does not handle edge cases (e.g., invalid email, unknown groups). Given the simplicity of the tool, the omission is a significant gap.
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 100% with minimal descriptions. The description reinforces that 'email' identifies the user and 'groups' are the groups to check, but adds no additional semantic detail beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Проверить' (check) and resource 'membership in groups', with specific inputs (email and list of groups). It immediately distinguishes from sibling tools like gc_add_to_groups and gc_remove_from_groups, which modify membership.
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 context 'мгновенно' (instantly) implies a quick, read-only operation. The purpose is clear enough that an agent can infer when to use this vs. sibling tools (e.g., for checking before adding/removing). However, no explicit when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Выдать пользователю такой же доступ, как у эталонного ученика (копирует его группы). filter — только группы с подстрокой. dryRun — предпросмотр.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Показать, что будет добавлено, без сохранения. | |
| filter | No | Копировать только группы, чьё название содержит подстроку. | |
| toEmail | Yes | Кому выдать такие же группы. | |
| fromEmail | Yes | Эталонный ученик, чьи группы копируем. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions copying groups (mutation) and provides dryRun for preview, which is good. However, it does not clarify if groups are added or replaced, nor does it describe permissions needed or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two sentences that front-load the main purpose and then specify optional parameters. No 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?
Given no annotations and no output schema, the description is fairly complete for a simple tool. But it lacks details on whether access is additive or replacive, error cases, and return behavior.
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 100%, baseline 3. The description adds meaning: filter is substring match, dryRun is preview without saving. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies access from a reference user to another user by copying groups. It specifies optional filtering and dry-run capability. This distinguishes it from sibling tools that add users to individual groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk copying of access but does not explicitly state when to use this tool versus alternatives like gc_add_to_groups. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создать заказ по офферам = выдать доступ покупкой (для тренингов «только купившие» группы доступ НЕ дают). 0₽ комп-оффер = доступ без денег. ⚠️ dryRun=false создаёт заказ СРАЗУ (без предпросмотра).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя (существующий). | ||
| dryRun | No | Только эхо, БЕЗ создания. ВНИМАНИЕ: при dryRun=false заказ создаётся сразу — у операции нет предпросмотра. | |
| offerIds | Yes | ID офферов (см. gc_find_offers). 0₽ комп-оффер = доступ без денег. | |
| tryPayFromDeposit | No | Попытаться оплатить с депозита (по умолчанию false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: immediate creation with dryRun=false, zero-ruble offers grant free access, and training groups behavior. However, it omits details on reversibility, permissions, 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 relatively concise with front-loaded purpose. It uses clear separators like ⚠️ for warnings. However, it could be slightly more compact by combining related statements.
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 no output schema and 4 parameters, the description covers the core functionality but lacks information about return values, error handling, or required permissions. It is adequate but not fully comprehensive for a mutation 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 100%, and the description adds context beyond the schema, such as email must exist, offerIds reference gc_find_offers, and dryRun warnings. The extra details enhance understanding without fully compensating for missing output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an order from offers and grants access via purchase, distinguishing it from sibling tools like gc_refund_order or gc_find_orders. It also explains special cases like zero-ruble comp-offers and the behavior for training groups.
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 does not explicitly specify when to use this tool versus alternatives or when not to use it. It lacks guidance on prerequisites or trade-offs with sibling tools like gc_add_to_groups or gc_copy_access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Найти офферы продажи по подстроке названия (id + цена + актуальность). Нужно для gc_create_order.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Подстрока названия оффера (например «Формула AI Полный доступ»). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool searches by substring and returns id, price, and relevance. It does not mention side effects, permissions, or rate limits, but given it's a read search, this is adequate.
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 two sentences long, concise and to the point. The second sentence could be integrated, but there is no extraneous information.
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 tool with one parameter and no output schema, the description is fairly complete: it explains the action, the search method, the return values, and the use case. It lacks details on pagination or edge cases, but is sufficient.
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 only parameter 'query' has a description in the schema and the tool description provides an example. With 100% schema coverage, the description adds marginal value, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: find offers by substring, returning id, price, and relevance. It also notes it's needed for gc_create_order, distinguishing it from sibling search tools like gc_find_orders and gc_find_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'Нужно для gc_create_order', indicating it's used before order creation. It does not explicitly list when not to use or alternatives, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список заказов (сделок) пользователя по email: dealId + статус + сумма.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'list' (implying read-only) but does not confirm safety, idempotency, or side effects. No mention of authentication, rate limits, or destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and results. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the purpose and return fields. It provides enough context for an agent to use 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 coverage is 100% and the description adds minimal extra meaning beyond 'by email'. The parameter email is already described in the schema, so the description doesn't significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists orders (deals) by email, specifying the returned fields (dealId, status, sum). This verb-resource combo distinguishes it from sibling tools like gc_create_order or gc_refund_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding orders by email but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are named, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Найти пользователя по email в списке пользователей (id, имя, тип, статус).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя для поиска. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it finds a user and returns certain fields, which is sufficient for a read-only lookup. It does not mention error conditions or if multiple matches possible, but for a simple search tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No 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?
Given the simplicity of the tool (one parameter, no output schema), the description covers the core functionality and expected output fields. It is complete enough for an agent to select and invoke correctly, though it lacks details on error handling.
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 100% with a description for the email parameter. The tool description adds value by specifying the output fields, which helps the agent understand what the parameter is used for (search by email and get user details).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'find user by email' and lists the output fields (id, name, type, status). It distinguishes from sibling tools which are mostly for other operations like add, remove, or find for offers/orders.
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 implicitly tells when to use this tool: when you need to find a user by email. No explicit alternatives or when-not-to-use guidance is given, but the context of sibling tools makes it clear this is the only find-user-by-email tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список категорий рассылок (tag-подобная сегментация): id + название. GetCourse не имеет свободных user-тегов — это группы + категории рассылок.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email любого пользователя (список категорий общий для аккаунта). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns id and name, and that the list is account-wide. However, it does not explicitly state that it is read-only or any potential side effects, authentication needs, or limitations.
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 two sentences long, front-loaded with the main purpose, and every sentence adds value. No redundant information.
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 no output schema or annotations, the description provides a clear picture of what the tool returns (id+name) and why the parameter is needed. It references sibling concepts (tags, groups) for context. Minor improvements could mention that the list is exhaustive or if there is pagination.
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 100%, and the description adds value by explaining that the email parameter is needed only to identify the account and that the list is common across users. This goes beyond the schema's basic type and requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List of mailing categories' with id+name, and provides context that these are tag-like segmentation distinct from groups. It distinguishes itself from sibling tools like gc_list_training_groups and gc_list_user_groups.
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?
Usage is implied by the name and context, but there is no explicit guidance on when to use this tool versus alternatives or prerequisites. The description mentions that GetCourse lacks free user tags, but does not direct the agent to use this tool before adding/removing categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список групп доступа, связанных с тренингом (id + название). filter — подстрока по названию.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Подстрока для фильтрации названий групп (регистронезависимо). | |
| trainingId | Yes | ID тренинга. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation (listing) but does not explicitly state safety, authentication needs, or potential side effects. The description is adequate but not thorough.
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 with no wasted words. The description is front-loaded with the core purpose, followed by parameter clarification.
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 tool with 2 parameters and no output schema, the description covers the main purpose and filter semantics. However, it lacks details on error handling (e.g., invalid trainingId), return format structure, and pagination, leaving some 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?
Schema coverage is 100%, so baseline is 3. The description adds context that filter is a substring on name and output includes id+name, but these are partially covered by schema descriptions. No significant extra semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists access groups related to a training, returning id and name. The verb 'list' and resource 'training groups' are specific, and the tool is distinct from siblings like gc_list_user_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving groups by training, but does not explicitly guide when to use it versus alternatives or when not to use it. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список групп, в которых состоит пользователь (id + название). filter — подстрока по названию.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. | ||
| filter | No | Подстрока для фильтрации названий групп (регистронезависимо). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions return fields (id, name) and filter behavior (case-insensitive substring match). No disclosure of pagination, limits, or authentication needs.
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. First sentence states purpose and output, second explains the filter parameter. No 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?
With 2 parameters and no output schema, the description covers essential behavior. Could mention empty result case, but adequate for a simple list 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 100% and descriptions are already present. The description adds only 'регистронезависимо' (case-insensitive) to filter, which is a minor addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists groups a user belongs to, returning id and name. It distinguishes from sibling add/remove/check 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?
The description implies usage for listing a user's groups with an optional filter. It lacks explicit guidance on when to use vs alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Оформить возврат денег по заказу через платёжный модуль Геткурса (реальный возврат на карту покупателя). Только для платежей через платформу Геткурс. НДС — как в чеке прихода (none = «без НДС»). dryRun — сводка без отправки.
| Name | Required | Description | Default |
|---|---|---|---|
| vat | No | Ставка НДС позиций возврата — как в чеке прихода (по умолчанию none = «без НДС»). | |
| amount | No | Сумма частичного возврата (только при одной позиции; по умолчанию полная стоимость). | |
| dealId | Yes | ID сделки (из gc_find_orders / gc_user_summary). | |
| dryRun | No | Заполнить форму возврата и показать сводку БЕЗ отправки (по умолчанию false). | |
| paymentId | No | ID платежа, если на сделке их несколько (список вернётся в ошибке). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description discloses real refund and dryRun mode but lacks details on side effects, authorization, or rate limits. Adequate but not thorough.
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?
Short paragraph with parameter details in dash-list style; every sentence contributes value. No 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?
Covers all parameters and action but lacks explanation of return values or error handling. Given no output schema, this is a notable gap.
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 100%; description adds meaningful context for vat, amount, dealId, dryRun, and paymentId (e.g., 'list returns in error').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it refunds money for an order via the Getcourse payment module, with real return to buyer's card. Distinguishes from siblings (no other refund tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies 'only for payments through Getcourse platform' and explains dryRun mode. Does not explicitly compare with alternatives but sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Убрать пользователя из групп = закрыть доступ (сохраняет остальные группы). dryRun — предпросмотр.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. | ||
| dryRun | No | Показать изменение без сохранения. | |
| groupIds | Yes | ID групп, из которых убрать (= закрыть доступ). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only mentions removal and dryRun as preview, omitting side effects, permissions, error handling, or what happens if groups don't exist. This is insufficient for a mutation 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 very short (two sentences) and gets to the point quickly. It is concise and front-loaded, though it sacrifices detail for brevity.
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 no output schema and sibling tools, the description lacks context on success criteria, error scenarios, and prerequisites. It is too minimal for a tool that modifies access rights.
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 100%, so baseline is 3. The description adds 'dryRun — preview' but otherwise repeats schema info. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'remove user from groups = close access' with the verb 'remove' and resource 'user from groups'. It distinguishes from sibling tools like 'gc_add_to_groups' by specifying removal and preserving other groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (remove user, preserve other groups) but does not explicitly state when to use this tool over alternatives like 'gc_add_to_groups' or 'gc_add_user_to_groups'. No when-not-to-use criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Убрать пользователя из категории рассылок (по categoryId).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. | ||
| categoryId | Yes | ID категории рассылок (см. gc_list_mailing_categories). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only says 'remove', which implies mutation but lacks details on consequences, permissions, or reversibility. This is insufficient for a mutation 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?
One short sentence with no unnecessary words. Efficient but could benefit from a brief outcome note.
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 2-parameter tool with no output schema, the description lacks crucial details like success indicators or error scenarios. It is minimally complete.
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 100% with clear parameter descriptions. The tool description adds minimal value by restating 'by categoryId', but does not provide additional context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove) and resource (mailing category by categoryId). It distinguishes from siblings like gc_add_to_mailing_category as the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., gc_remove_from_groups, gc_check_membership). An agent must infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Изменить статус сделки (напр. отменить дубль: status=cancelled + cancelReasonId).
| Name | Required | Description | Default |
|---|---|---|---|
| dealId | Yes | ID сделки (из gc_find_orders или URL /sales/control/deal/update/id/<id>). | |
| status | Yes | Новый статус сделки. | |
| cancelReasonId | No | ID причины отмены для status=cancelled (напр. «Дубль заказа»=54347 на li-ft.ru). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the operation is destructive, reversible, or requires authentication. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action and a key use case. No redundant information, and the core purpose 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 simple mutation tool, the description is minimally adequate but lacks details on return values, error handling, or side effects. Without an output schema, more context would help, especially for status changes beyond cancellation.
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 100%, but the description adds valuable context by explaining the use of cancelReasonId and providing a concrete example ID. This enhances understanding beyond the schema, though other parameters are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes deal status and provides an example (cancel duplicate). It distinguishes itself from mutation tools like gc_refund_order or gc_create_order, though it could be more explicit about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like gc_refund_order or gc_find_orders. The example implies usage for cancellation, but no when-not or prerequisites (e.g., needing dealId from gc_find_orders).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Проверить сессию GetCourse: залогинен ли администратор в браузере по CDP.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly implies a read-only check but does not disclose the return format (e.g., boolean, status object) or any potential side effects. Adequate for a simple tool but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence in Russian that conveys the entire purpose without any extraneous words. Highly efficient.
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 parameterless status-check tool, the description covers the essential aspects: what is checked, who, and how. The only omission is the return value format, but the tool's simplicity makes this a minor gap.
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 zero parameters, baseline is 4. The description adds context by specifying the session type (administrator login via CDP), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('проверить' – check) and resource ('сессию GetCourse' – session), clearly indicating the tool checks the administrator's login session via CDP. This distinguishes it from sibling tools that perform actions like adding, removing, or updating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool compared to siblings. It does not mention prerequisites, context, or alternatives, leaving the agent without decision support for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Изменить поля профиля на карточке (имя/фамилия/телефон/город/комментарий). Email вне области. dryRun — без сохранения.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Город. | |
| Yes | Email пользователя. | ||
| phone | No | Телефон. | |
| dryRun | No | Заполнить поля без сохранения. | |
| comment | No | Комментарий. | |
| lastName | No | Фамилия. | |
| firstName | No | Имя. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool modifies fields and offers a dry run option, but does not mention side effects, authorization needs, rate limits, or what happens on conflict. The constraint about email is useful but minimal.
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 no fluff. The most important information (verb, fields, constraint) is front-loaded. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description is adequate but not complete. It explains the main action and dryRun, but does not mention return values, idempotency, or error behavior. It covers the immediate need but leaves gaps for a complex 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?
With 100% schema description coverage, baseline is 3. The description adds value by grouping the modifiable fields and explaining that email is the identifier (not modifiable), and clarifying the dryRun parameter's purpose. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'change' and the resource 'profile fields on the card', listing the specific fields. It also notes that email is out of scope, which helps clarify purpose. However, it does not explicitly distinguish from sibling tools, but the context makes it clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating user profile fields and mentions dryRun for testing without saving, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions beyond email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сводка по пользователю за один вызов: профиль + группы + заказы.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email пользователя. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates the tool returns a summary (profile, groups, orders) but does not explicitly state that it is a read-only operation or disclose any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides enough context to understand the tool's role as a combined summary. It lists the three components but lacks detail on the output format, which could be important for an agent.
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 100% with a single parameter 'email' described as 'User email.' The description adds no additional semantic meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a user summary containing profile, groups, and orders in a single call. It differentiates from sibling tools like gc_find_user and gc_list_user_groups by combining multiple data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is efficient for retrieving multiple related data at once, but it does not explicitly state when to use it versus alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0gc_add_to_groupsgc_add_to_mailing_categorygc_add_user_to_groupsgc_check_membershipgc_copy_accessgc_create_ordergc_find_offersgc_find_ordersgc_find_usergc_list_mailing_categoriesgc_list_training_groupsgc_list_user_groupsgc_refund_ordergc_remove_from_groupsgc_remove_from_mailing_categorygc_set_order_statusgc_statusgc_update_usergc_user_summaryMost tools have distinct purposes, though gc_add_to_groups and gc_add_user_to_groups both add users to groups, requiring careful reading of descriptions to differentiate (one is clean, the other imports). Overall, descriptions are detailed enough to avoid confusion.
All tools follow a consistent gc_verb_noun pattern (e.g., gc_add_to_groups, gc_find_offers), with only minor exceptions like gc_status and gc_user_summary, but the style remains uniform and predictable.
With 19 tools covering user, group, order, and mailing management, the count is well-scoped for a GetCourse MCP server. Each tool serves a clear purpose without unnecessary redundancy.
The tool set covers core workflows (CRUD for users, groups, orders) but lacks tools for creating groups or listing all groups. These gaps are minor and can be worked around using existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/skiddgoddamn/getcourse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
