Query the full BC K-12 curriculum: Big Ideas, Competencies, Content, and more.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.4/5.
Each tool has a distinct primary purpose: listing courses, fetching full curriculum, searching, tracking progression, and finding cross-curricular connections. The only potential overlap is between get_competency_connections and search_cross_curricular, both of which handle cross-subject discovery, but they differ in input and output (one is competency-text-driven, the other is grade-and-subject-comparison-driven), so confusion is unlikely with clear descriptions.
All tool names follow a consistent verb_noun pattern using snake_case: get_ for retrievals, list_ for enumeration, and search_ for searching. The naming clearly reflects each tool's function, and there are no mixed conventions or vague verbs.
Eight tools is a well-scoped count for a curriculum data server. The set covers the essential needs: discovery (list_courses, search_curriculum), detailed retrieval (get_course_curriculum), cross-curricular analysis (get_competency_connections, search_cross_curricular), progression tracking (get_grade_progression), and change monitoring (get_course_history, get_curriculum_changes). Each tool earns its place without redundancy.
The tool surface is quite complete for read-only curriculum access and analysis: it covers listing, full retrieval, search, cross-subject comparison, grade progression, and change/history tracking. A minor gap is that there is no dedicated tool to enumerate subjects or grades independently, though list_courses can filter by subject/grade and indirectly provides that information.
get_competency_connectionsGet Competency ConnectionsAFind curricular competencies that appear across multiple subjects or courses. Useful for interdisciplinary curriculum design and identifying transferable skills.
Args:
competency_text (string): A competency description to find connections for
scope (string, optional): Where to search ('same_subject', 'cross_subject', 'all'). Default 'all'.
Returns: Related competencies from other courses/subjects with similarity ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Where to search for related competencies | all |
| competency_text | Yes | A competency description to find connections for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds behavioral details such as the default scope ('Default 'all'') and the return format ('Related competencies from other courses/subjects with similarity ranking'). This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized, starting with a one-sentence purpose, then a use-case clause, a concise Args list, and a Returns line. No unnecessary text.
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 read-only tool with two parameters and no output schema, the description covers purpose, usage context, parameter details, and return values. This is sufficient for an agent to invoke the tool 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?
The input schema already covers both parameters with descriptions and the enum/default for scope. The description repeats this information without adding extra meaning, so it meets the baseline for full schema coverage.
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 'Find' and identifies the resource as 'curricular competencies that appear across multiple subjects or courses,' which clearly states the tool's function. It also provides a use case ('interdisciplinary curriculum design') and differentiates from generic search by focusing on connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is 'Useful for interdisciplinary curriculum design and identifying transferable skills,' giving context for when to use it. However, it does not explicitly mention alternatives or exclusions relative to sibling tools like search_cross_curricular.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_course_curriculumGet Course CurriculumAGet the complete BC curriculum for a specific course: Big Ideas, Curricular Competencies (grouped by domain), and Content/KDU items with elaborations. Returns the full three-column structure used by BC Ministry of Education.
Args:
subject (string): Subject slug (e.g., 'adst', 'science')
grade (integer): Grade level (0=K, 1-12)
course (string, optional): Course slug (e.g., 'technology-explorations'). If omitted, returns all courses for that subject+grade.
Returns: Complete three-column curriculum structure per course, including elaborations.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | Yes | Grade level (0=Kindergarten, 1-12) | |
| course | No | Course slug (e.g., 'technology-explorations'). If omitted, returns all courses for subject+grade. | |
| subject | Yes | BC curriculum subject slug (e.g., 'adst', 'science') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only and idempotent. The description adds valuable behavioral details: it returns a three-column structure, includes elaborations, and explains that omitting course returns all courses for the subject/grade. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, a bulleted Args section, and a Returns line. It is slightly redundant with the schema's parameter descriptions but remains readable and focused.
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 that there is no output schema, the description does a good job of explaining what the tool returns, including the three-column structure and elaborations. It also clarifies the behavior when the optional course parameter is omitted, making it sufficient for this straightforward 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?
The input schema already provides full descriptions for all three parameters (100% coverage). The description's Args section essentially repeats this information without adding new semantics about formats or constraints, so it meets the baseline but does not exceed 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 opens with a specific verb 'Get' and identifies the resource: the complete BC curriculum for a specific course. It lists the exact components (Big Ideas, Curricular Competencies, Content/KDU) and notes the three-column structure, which clearly differentiates it from sibling search/list 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 when to use this tool (when the full curriculum structure for a course is needed) but does not explicitly compare it to alternatives or state when not to use it. No exclusions are mentioned, so it falls short of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_course_historyGet Course HistoryAShow the crawl history and change timeline for a specific course. Includes each crawl snapshot (date, item counts, content hash) and a changelog of all detected modifications.
Args:
subject (string): Subject slug (e.g., 'science')
grade (integer): Grade level (0=K, 1-12)
course (string, optional): Course slug (e.g., 'chemistry'). If omitted, shows history for all courses at subject+grade.
Returns: Timeline of crawl snapshots and detected changes per course.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | Yes | Grade level (0=Kindergarten, 1-12) | |
| course | No | Course slug (e.g., 'chemistry'). If omitted, shows history for all courses at subject+grade. | |
| subject | Yes | BC curriculum subject slug (e.g., 'adst', 'science') |
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 absence of safety disclaimers is acceptable. The description adds useful behavioral context beyond annotations by detailing what the timeline contains (crawl snapshots with dates, item counts, content hash) and the optional aggregation behavior when course is omitted, which is valuable for predicting outputs.
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 concise and well-structured: a single clear purpose sentence, followed by a compact Args list and a Returns line. No fluff or redundancy; every sentence contributes essential 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?
No output schema exists, so the description must convey return value expectations; the 'Returns' line provides a high-level summary (timeline of snapshots and changes). It covers the required parameters, optional behavior, and primary output, but could be more explicit about the structure or sorting of the timeline. Still, for a read-only history tool with good annotations, it is sufficiently 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 description coverage is 100%, so the input schema already documents each parameter's meaning and constraints. The description repeats the parameter details without adding new semantics; the only slight addition is reiterating that omitting course returns history for all courses, which is already in the schema. Baseline 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 uses a specific verb ('Show') and clearly identifies the resource ('crawl history and change timeline for a specific course'), distinguishing it from sibling tools like get_curriculum_changes by emphasizing crawl snapshots and content hashes. It also scopes the operation via subject/grade/course parameters.
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 such as get_curriculum_changes or get_course_curriculum. The description only implies usage by describing its functionality and notes optional course omission, but does not state when one should choose this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_curriculum_changesGet Curriculum ChangesAShow what changed in BC curriculum since a given date. Detects added, removed, and modified Big Ideas, Competencies, and Content items across crawl runs. Requires at least two crawls to have change data.
Args:
since (string, optional): ISO date (e.g., '2026-01-15'). Default: last 30 days.
subject (string, optional): Filter by subject slug
grade (integer, optional): Filter by grade level
change_type (string, optional): Filter by change type ('added', 'removed', 'modified', 'all'). Default 'all'.
limit (integer, optional): Max entries to return (default 50, max 100)
Returns: Course-level summary of which courses changed, plus item-level detail of what specifically was added/removed/modified.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Grade level (0=Kindergarten, 1-12) | |
| limit | No | Maximum changelog entries to return (default 50) | |
| since | No | ISO date string — show changes detected after this date (e.g., '2026-01-15'). Defaults to last 30 days. | |
| subject | No | BC curriculum subject slug (e.g., 'adst', 'science') | |
| change_type | No | Filter by type of change | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context: it requires at least two crawls, detects three types of changes, and returns both course-level summaries and item-level details. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a short purpose statement, a single clarifying sentence, a bulleted Args list, and a Returns line. Every sentence earns its place, and the structure makes it easy to scan.
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?
Despite having no output schema, the description explains the return format (course-level summary plus item-level detail). It also covers prerequisites (two crawls), parameter behavior, and the scope of the tool (Big Ideas, Competencies, Content). This is complete for a read-only list tool with optional filters.
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 input schema provides 100% coverage with descriptions for all five parameters. The description's Args section largely restates the schema, but it does add clarity by explicitly listing defaults for since and change_type and mentioning that grade 0 is Kindergarten. Since the schema already documents these, the description adds only marginal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show what changed in BC curriculum since a given date,' and goes on to specify the exact item types (Big Ideas, Competencies, Content) and the mechanism (crawl runs). This clearly distinguishes it from sibling tools like get_course_history, which focuses on a single course's history.
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 provides clear context (changes since a date, across crawl runs) and an explicit prerequisite ('Requires at least two crawls'). It does not name alternative tools or explicitly state when not to use it, but the context is sufficient for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_grade_progressionGet Grade ProgressionAShow how Big Ideas, Competencies, and Content progress across grade levels for a BC subject. Useful for understanding scaffolding, prerequisites, and learning trajectories. When a query is provided, filters to only matching items at each grade — showing a focused vertical thread rather than a full data dump.
Args:
subject (string): Subject slug
grade_from (integer): Starting grade (0=K, 1-12)
grade_to (integer): Ending grade (0=K, 1-12)
focus (string, optional): Which element to trace ('big_ideas', 'competencies', 'content', 'all'). Default 'all'.
query (string, optional): Focus on a specific concept (e.g., 'evidence', 'multiplication'). Only matching items shown at each grade.
Returns: Grade-by-grade breakdown of curriculum elements showing progression, optionally filtered to a concept thread.
| 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. The description adds valuable behavioral context: query filtering produces 'a focused vertical thread rather than a full data dump' and the result is a grade-by-grade breakdown. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by usage context, a clean Args section with each parameter on its own line, and a Returns line. There is no filler; every sentence earns its place, and the structure makes it easy to scan.
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 empty input schema and lack of output schema, the description fully compensates by covering purpose, parameter semantics, filtering behavior, and return shape. The 'Returns' line is sufficient, and the tool is a read-only lookup, so the overall information is complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema exposes zero properties, the description fully documents all five parameters with types, defaults, and examples (e.g., focus enum values and query examples like 'evidence'). This exceeds the baseline for 0 params and makes the tool highly usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show how Big Ideas, Competencies, and Content progress across grade levels for a BC subject.' This clearly defines the tool's scope and differentiates it from siblings like get_course_curriculum or search_curriculum by focusing on vertical grade-level progression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is 'useful for understanding scaffolding, prerequisites, and learning trajectories' and explains when to use the query filter ('when a query is provided...'). However, it doesn't mention when not to use this tool or name specific alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_coursesList BC CoursesAList all available courses in the BC curriculum database (K-12). Use this to discover what courses are available before querying specific curriculum data.
Args:
subject (string, optional): Filter by subject slug
grade (integer, optional): Filter by grade level (0=K, 1-12)
Returns: List of courses with subject, grade, name, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Grade level (0=Kindergarten, 1-12) | |
| subject | No | BC curriculum subject slug (e.g., 'adst', 'science') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety. The description adds value by disclosing the return format ('List of courses with subject, grade, name, and URL') and the scope (K-12, all available courses). No contradictions with annotations exist, and the added behavioral detail is useful without being redundant.
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 concise and effectively front-loaded with the primary action and purpose. It includes a clear usage hint, a compact list of args, and a return description. Every sentence serves a distinct purpose, and the structure (intro, when-to-use, args, returns) makes it easy to scan.
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?
Despite lacking an output schema, the description explicitly specifies the return fields (subject, grade, name, URL). It also clarifies the tool's scope (K-12 database, all courses) and its role in the workflow (discovery before querying specific data). Given the tool's simplicity (2 optional params) and strong annotations, the description fully covers 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?
The input schema already covers 100% of parameter descriptions, providing both `subject` enum values and `grade` range with K/1-12 semantics. The description's 'Args' section essentially repeats the schema information without adding new details like examples, default behavior, or filtering semantics. Since schema coverage is high, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List all available courses') with a defined resource ('BC curriculum database (K-12)') and scope ('all available courses'). It positions itself as a discovery tool separate from sibling tools like get_course_curriculum or search_curriculum, which are implied as follow-up actions ('before querying specific curriculum data').
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?
Explicit guidance is provided: 'Use this to discover what courses are available before querying specific curriculum data.' This gives clear when-to-use context and implies that other sibling tools are for querying specific curriculum data. However, it does not explicitly name alternatives or describe when not to use this tool versus those alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cross_curricularSearch Cross-Curricular ConnectionsAFind curriculum elements shared between two or more subjects at the same grade level. Identifies overlapping competencies, big ideas, and content across subjects. Essential for interdisciplinary planning.
Args:
subjects (string[]): Two or more subject slugs to compare (e.g., ['science', 'adst'])
grade (integer): Grade level (0=K, 1-12)
focus (string, optional): Which element to compare ('big_ideas', 'competencies', 'content', 'all'). Default 'all'.
query (string, optional): Narrow to a specific concept (e.g., 'evidence', 'design thinking')
limit (integer, optional): Max connections to return (default 20, max 50)
Returns: Groups of curriculum items connected by shared language across subjects.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Which curriculum element to compare across subjects | all |
| grade | Yes | Grade level (0=Kindergarten, 1-12) | |
| limit | No | Maximum connections to return (default 20) | |
| query | No | Optional: narrow to a specific concept (e.g., 'evidence', 'design thinking') | |
| subjects | Yes | Two or more subject slugs to compare (e.g., ['science', 'adst']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the annotations (readOnlyHint=true, idempotentHint=true) by stating it is a search operation. It adds behavioral detail beyond the schema and annotations by specifying the return format: 'Groups of curriculum items connected by shared language across subjects.' Since there is no output schema, this is valuable context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. The Args list is useful as a quick reference but redundantly mirrors the schema, and the Returns line adds critical output information. Overall it is efficient with minor duplication, earning a 4.
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 5-parameter tool with no output schema, the description provides essential information: purpose, usage context, parameter details (via schema), and return format. It lacks a more detailed output structure but does not mislead. The annotations cover safety, making it reasonably complete for the tool's complexity.
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 schema covers all 5 parameters with clear descriptions and enums, achieving 100% coverage. The description's Args section essentially restates the schema (same examples, defaults, and enum values) without adding new meaning. The baseline for high schema coverage is 3, and the description does not elevate beyond that.
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 'Find' and resource 'curriculum elements shared between two or more subjects at the same grade level,' then clarifies it identifies overlapping competencies, big ideas, and content. This clearly distinguishes it from sibling tools like search_curriculum (general search) and get_competency_connections (likely single-subject). The purpose is explicit and unambiguous.
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 states 'Essential for interdisciplinary planning,' giving a clear use context. This tells the agent when the tool is appropriate, though it does not explicitly name alternatives or exclusions. It is more explicit than an implied usage but lacks a full when/when-not comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_curriculumSearch BC CurriculumBSearch BC curriculum (K-12) for standards, competencies, content items, and assessment resources using full-text search. Returns structured results with source metadata.
Args:
query (string): Natural language search query (e.g., 'empathetic design thinking', 'coding and computational thinking')
subject (string, optional): Filter by subject slug (e.g., 'adst', 'science')
grade (integer, optional): Filter by grade level (0=K, 1-12)
content_type (string, optional): Filter by content type ('big_idea', 'competency', 'content_item', 'elaboration', 'assessment', 'all')
limit (integer, optional): Max results (default 10, max 50)
Returns: Matching curriculum elements with source type, course, subject, and grade metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Grade level (0=Kindergarten, 1-12) | |
| limit | No | Maximum results to return (default 10) | |
| query | Yes | Natural language search query (e.g., 'empathetic design thinking') | |
| subject | No | BC curriculum subject slug (e.g., 'adst', 'science') | |
| content_type | No | Type of curriculum content to filter by | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety profile is known. The description adds that it performs full-text search and returns structured results with source metadata, which is useful context. However, it does not disclose rate limits, auth needs, or any non-obvious behavior like default pagination limits beyond what the schema already states.
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 moderately concise and well-structured with a summary line, Args section, and Returns section. However, the Args section largely duplicates the schema descriptions, creating some redundancy. It is still front-loaded with the most important usage information in the summary sentence.
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?
There is no output schema, so the Returns section provides a brief list of metadata fields (source type, course, subject, grade) which is helpful but not a full structure. The incomplete content_type list in the description and lack of pagination/edge-case details leave gaps for a tool with five params. Given the complexity, the description is adequate but not thorough.
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 input schema has 100% description coverage, but the description's Args section omits 'instructional_sample' from the content_type filter list, even though the schema enum includes it. This could mislead an agent into thinking 'instructional_sample' is not a valid value. The description does add example queries, but this inaccuracy undermines its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches BC curriculum (K-12) for standards, competencies, content items, and assessment resources using full-text search. This gives a specific verb, resource, and scope. However, it does not explicitly distinguish this from the sibling tool 'search_cross_curricular', which could cause confusion about which search tool to use.
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 provides clear context on what the tool can search (curriculum content types, with filters for subject, grade, content_type) and includes example queries. It does not mention exclusions or when to prefer alternative tools like 'get_course_curriculum' or 'search_cross_curricular', so it falls short of explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!