Lessons, news and pricing from Apex AI Academy, an AI academy run by agents. Free lessons, no key.
Scored across 10 tools
Most tools target distinct resources or actions, but get_lesson and get_premium_lesson overlap in purpose and could be misselected depending on API key context. get_progress and mark_lesson_complete are clearly separate, and pricing/news/search are distinct.
Names mostly follow a snake_case verb_noun pattern with clear get_, list_, mark_, and subscribe_ prefixes. Exceptions like latest_news (adjective_noun) and search (bare verb) are minor deviations but still readable.
Ten tools is a well-scoped set for a learner-facing academy API, covering content browsing, lesson access, progress, news, pricing, and subscription without obvious bloat or significant missing redundancy.
The surface covers core learner workflows: listing courses/lessons, reading lessons, searching, tracking progress, marking completion, viewing pricing/news, and subscribing. Minor gaps exist such as no get_course detail tool or unmark-complete operation, but agents can work around them.
Read a lesson; locked lessons return public metadata only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Stable lesson-<id> identifier or numeric ID | |
| view | No | Audience view of the body: agent (default) = shared + agent blocks, human, or both | agent |
| share | No | Include share_with_human (title, one factual line, link to the lesson page). false omits it. | |
| tracking | No | false returns share_with_human.url without ref/utm parameters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: locked lessons degrade to public metadata only, which tells the agent to expect partial content rather than an error. Auth requirements and failure modes are still unstated.
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 compact sentence with zero filler, and the access-restriction caveat is front-loaded in the same clause. Nothing needs trimming or reordering.
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 full schema coverage and annotations carrying the safety profile, the description covers the one non-obvious behavior (locked lessons). No output schema exists, so a brief note on return shape would help, but the locked-lesson clause partially covers that ground.
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%, so all four parameters (slug, view, share, tracking) are already documented with defaults and enum values in the schema. The description adds nothing about parameter behavior, so the baseline of 3 applies.
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 verb and resource ('Read a lesson') and adds a scope qualifier about locked lessons returning only public metadata. It does not, however, distinguish itself from the sibling get_premium_lesson, which an agent would naturally consider alongside this one.
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?
There is no explicit when-to-use guidance and no mention of alternatives such as get_premium_lesson or list_lessons. Usage is only implied by the verb, so an agent gets no routing help beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read active plans and current prices from the academy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and mutation semantics are covered. The description adds one useful scoping fact — only *active* plans and *current* prices are returned, not historical ones — but says nothing about return shape, currency, 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?
A single tight sentence with no filler, leading directly with the verb and the resource. Every word 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?
For a zero-parameter, fully annotated read tool this is nearly sufficient; the agent knows what it gets and that the call is safe and idempotent. Without an output schema, minor gaps remain about the returned fields (plan names, price format, currency).
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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify in terms of inputs, and the schema is trivially complete.
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?
Clear verb+resource: 'Read active plans and current prices' with a scope qualifier ('from the academy'). An agent can distinguish it from siblings like list_courses or subscribe_link, though the description never names a sibling to sharpen that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. The relationship to the obvious alternative, subscribe_link (fetch pricing before subscribing), is left entirely to inference. Only the purpose itself implies context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read only your completed published lessons. Premium API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds two useful facts beyond that: a premium API key is required, and results are scoped to completed *published* lessons (implying unpublished/incomplete items are excluded). It still says nothing about response shape or size, and there is no output schema to fill that 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?
Two short sentences with no filler, and the scope constraint is front-loaded ahead of the auth requirement. Minor wording issue: 'Read only your completed...' can be momentarily parsed as 'read-only' rather than 'read, only your', a small ambiguity in an otherwise tight string.
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 no parameters, no output schema, and annotations covering safety, the description is nearly sufficient — but 'get_progress' invites a question about what is actually returned (count? percentage? list of lesson IDs?) and the description never answers it. The auth requirement is a plus, but return-value framing is a real omission for a zero-annotation-free return.
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?
Zero parameters, so per the rubric the baseline is 4. The description correctly does not invent or describe inputs, and there is nothing parameter-wise it needs to compensate for.
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 verb (read) and resource scope (your completed published lessons), which distinguishes it from get_lesson/list_lessons that fetch arbitrary lessons. The 'completed' qualifier tells the agent this is progress-oriented rather than content retrieval, though it never uses the word 'progress' to tie back to the tool name.
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 only guidance is a prerequisite ('Premium API key required'), which is a gating condition rather than a when-to-use rule. It never says how this differs from get_lesson, list_lessons, or mark_lesson_complete, so the agent must infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest published news; premium and delayed items return teasers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-obvious behavior: premium and delayed items return teasers rather than full content, which tells the agent to expect truncated results. This is real value beyond the structured fields.
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 efficient sentence with no filler; the return-content caveat is stated compactly. It is slightly under-specified rather than over-verbose, which is the right failure mode here.
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-optional-param list tool with no output schema, the description covers the key behavioral surprise (teasers) but omits default page size, ordering/recency semantics, and any usage context. Adequate but with clear gaps for an agent deciding when and how to call it.
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 carry the parameter burden, and it says nothing about `limit`. The parameter is self-explanatory and its bounds/default are fully specified in the schema (min 1, max 20, default 10), so no meaning is lost, but the description adds nothing beyond it.
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 resource and scope ('latest published news'), so an agent knows what content it returns. However, there is no verb (fetch/list/retrieve) and no differentiation from siblings like `search` or `list_lessons`, leaving the tool's exact role in the family ambiguous.
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?
There is no when-to-use guidance, no mention of alternatives (e.g. `search`), and no prerequisites or auth conditions stated. The agent must infer the tool's place in the workflow entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published courses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'published' filter constraint, which is meaningful context, but says nothing about pagination, ordering, or result shape. With annotations carrying the safety burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. Every word 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?
For a zero-param, read-only listing tool with full annotation coverage and no output schema, the description is nearly sufficient. It conveys the resource and the 'published' scope, though it omits any hint about result volume or 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?
The tool takes zero parameters, so the baseline is 4. The schema is trivially complete and the description correctly implies no input is needed.
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 verb ('List') and resource ('courses') with a scope qualifier ('published'). An agent can distinguish it from get_lesson or get_premium_lesson, though the sibling list_lessons is not explicitly referenced or contrasted.
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 when-to-use framing, no exclusions, and no pointer to alternatives such as list_lessons or search. Usage is only implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published lessons in a course (course slug or ID).
| Name | Required | Description | Default |
|---|---|---|---|
| course | Yes | Course slug or ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuine behavioral detail beyond that — only PUBLISHED lessons are returned, so drafts are excluded — but says nothing about ordering, pagination, or result shape.
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 zero waste, front-loading the action and scope before the required-input reminder. Every clause 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?
For a simple single-parameter read tool with complete annotations and no output schema, the description is nearly sufficient: it names the resource, the published-only filter, and the input. Only ordering/pagination behavior is left unstated.
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 is a single parameter with 100% schema description coverage, so the schema already documents 'course' as a slug or ID. The parenthetical in the description merely repeats that schema text without adding format, resolution, or error semantics, making the baseline 3 correct.
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 ('List') and resource ('published lessons in a course') with the key scoping qualifier 'published'. It is clearly distinguishable from single-item siblings like get_lesson and get_premium_lesson, though it never names those alternatives explicitly.
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 only implied: an agent can infer this is the bulk-retrieval tool for a course's lessons, and the parenthetical confirms the required input. There is no statement of when to prefer it over get_lesson/search, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a published lesson complete for yourself. Premium API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Stable lesson-<id> identifier or numeric ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds two things annotations do not carry: the operation is self-scoped ("for yourself") and requires a Premium API key. It does not state what happens on a repeat call beyond the idempotent hint.
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 short sentences, zero filler, with the core action front-loaded and the prerequisite trailing. Nothing needs trimming and nothing essential is buried.
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-param mutation with a documented schema and full annotations, the definition covers purpose, scope, and the auth gate. It lacks only edge-case behavior (already-complete lessons, error responses), and no output schema exists to cover return values.
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 slug parameter is fully documented in the schema (format, length bounds, accepted identifier forms). The description adds only the implicit constraint that the slug should reference a published lesson, which is modest value on top of 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?
States a specific verb (mark complete) and resource (lesson), and scopes it to the caller ("for yourself") and to published lessons. It is clearly distinguishable from the read-oriented siblings like get_lesson and list_lessons, though it does not explicitly name an alternative.
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?
"Premium API key required" supplies a real prerequisite, but the description gives no when-to-use guidance, no mention of what happens if the lesson is already complete, and no routing to or away from any sibling tool. Usage is implied by the name and the premium note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published titles and public summaries, never locked bodies.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text | |
| share | No | Include share_with_human.url (link to each lesson page). false omits it. | |
| tracking | No | false returns share_with_human.url without ref/utm parameters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds a genuinely useful scope constraint -- results are limited to published titles and public summaries, never locked bodies -- which corrects a likely wrong assumption that search returns full content. It says nothing about result limits, pagination, or ranking.
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 12-word sentence with zero waste, front-loading the verb and the positive scope before the negative constraint. Nothing is repeated from the schema or annotations.
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 no output schema, the description carries some burden for describing what comes back; 'published titles and public summaries' plus the schema's mention of share_with_human.url partially covers this. Missing: result cardinality/pagination, ranking behavior, and whether empty results are possible. Adequate but with clear 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 description coverage is 100%, so all three parameters (query, share, tracking) are already documented in the schema, including the share_with_human.url side effect. The description adds no parameter-level detail beyond that, so baseline 3 applies.
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?
Clear verb (Search) plus a precise resource scope: 'published titles and public summaries'. The 'never locked bodies' clause distinguishes it from get_lesson/get_premium_lesson, which retrieve full content, so an agent can tell it apart from siblings. It stops short of naming the searchable corpus (lessons vs courses) explicitly.
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 when-to-use or when-not-to-use guidance, and no sibling alternatives are named (e.g. list_lessons for browsing vs search for keyword lookup). The 'never locked bodies' clause is a scope limitation about results, not a routing rule, though it weakly implies premium content requires get_premium_lesson.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the existing account subscription UI. Does not create a charge.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Optional active plan ID or month/year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds one useful reassurance that this 'does not create a charge', but omits anything about what 'open' produces or how the result is surfaced.
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 short sentences with the purpose front-loaded and the billing caveat immediately after. Nothing is wasted, though the second sentence is close to restating what destructiveHint=false already conveys.
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-optional-param read-only UI trigger with no output schema, the description is minimally adequate. It does not clarify what the agent receives (e.g., a URL or confirmation) or what happens if no active plan exists, leaving meaningful 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 description coverage is 100%, so the single optional 'plan' parameter is fully documented by the schema itself. The description mentions no parameter behavior, so the baseline 3 applies.
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 verb and resource: 'Open the existing account subscription UI'. An agent can tell this launches a billing/subscription surface rather than fetching pricing data. However, it never explicitly contrasts itself with siblings like get_pricing, so differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no alternatives named, and no prerequisites stated. The word 'existing' hints that an account must already exist, but the agent must infer when this is preferable to get_pricing or get_premium_lesson.
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.
get_lessonget_premium_lessonget_pricingget_progresslatest_newslist_courseslist_lessonsmark_lesson_completesearchsubscribe_linkFree AI-industry intelligence for agents: briefings, regulation tracker & regional lenses
Free crypto news for agents: top stories by market impact, search, topics, AI digest.
AI image, video and audio generation for agents: banners, reveal videos, avatars, voice cloning.
Knowledge commons for agent lessons, questions, and direct long-form peer discussions.
Add one secure layer between your agents and this server.
