Skip to main content
Glama

CourseProfiler

by com.courseprofiler

Submit course

submit_course

Submit an official/trusted course for CourseProfiler catalog review. This is the only MCP tool that creates a catalog-review submission; import_course, enrich_course_waypoints, and generate_course_segments only create temporary artifacts. A final CRSProf artifact is not a submission. If there is no submission_id in the submit_course result, the course has not been submitted. Use this only when the user asked to submit/add/update a course in the catalog. Do not call submit_course for normal race-plan creation; create_race_plan does not require catalog submission. Before calling submit_course, collect and pass event metadata from official sources whenever available: main event/race name, specific course name, year/date, start time, location/city/region and country, distance, elevation gain, organizer, applicable tags/types, competitions/series, official race page, route source URL, aid-chart/regulation URLs, and other source URLs. Use metadata.event.name for the main event and metadata.event.course for the specific course (example: name='Speedgoat Mountain Races', course='50K'); do not put distance/elevation stats in the course name (bad: 'Skyrace — 32 km, +2400 m'); location must not include country because metadata.event.country is separate. Add metadata.event.types tags where they apply, and metadata.event.competitions for circuits/series/championships such as Golden Trail World Series (GTWS). Put the race start time in metadata.event.time when known. Put catalog UI event links in metadata.event.links, not just metadata.source_urls; supported types include info, registration, rules, schedule, course, cutoff, parking, bib_pickup, wardrobe, results, and contact. Include official General Information (type=info), Registration (registration), Rules/Regulations (rules), Schedule/Program (schedule), Course (course), Cut-off times (cutoff), Parking (parking), Bib pick-up (bib_pickup), Wardrobe/drop bag (wardrobe), Results (results), and Contact (contact) links when available. This metadata is important for catalog review and discoverability. Do not invent unknown values; omit unconfirmed fields rather than guessing. Use this after discovering the official route source externally, importing a real GPX/FIT/CRSProf/ZIP-with-one-GPX source, enriching waypoints/resources/cutoffs when official data is available, applying metadata, and generating segments. Do not submit reconstructed/synthetic course geometry from roadbooks, checkpoint tables, elevation profiles, aid-station lists, screenshots, or regulations; those are enrichment/context only. If route links are blocked, stop and ask the user to upload the official GPX/FIT/CRSProf/ZIP through REST artifact upload or pass inline/proxied file content. Search the CourseProfiler catalog first to avoid duplicates or to identify updates. If official waypoint/aid documents conflict or are incomplete, ask the user to confirm and include only confirmed aid stations; do not invent locations. Returns a job whose progress includes submission_id and final_crsprof_artifact_id, and whose artifacts include the final CRSProf submitted for review. Report both IDs to the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courseYes
metadataNo
race_nameNoRace/course name to submit. Assistants should search the catalog and official web sources before calling submit_course, then populate metadata.event from official sources, including metadata.event.time and metadata.event.links when available.
submitterNo
course_fileNoInline/proxied GPX, FIT, CRSProf, or ZIP-with-one-GPX file object to import. Use content for text GPX/XML/JSON/CRSProf or base64 for FIT/ZIP/binary. Bare local filesystem paths and file:// URLs are rejected.
original_file_nameNoOptional original route/profile file name for review metadata.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorsNo
job_idYesCourseProfiler job ID to poll with get_job.
statusYesJob status, e.g. queued, running, succeeded, or failed.
progressNo
warningsNo
created_atNoISO-8601 creation timestamp.
expires_atNoISO-8601 expiration timestamp.
started_atNoISO-8601 start timestamp, when available.
status_urlNoRelative API URL for polling this job.
completed_atNoISO-8601 completion timestamp, when available.
result_artifactsNoArtifacts produced by the job, including role metadata.

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure and does so excellently. It reveals that a final CRSProf artifact is not a submission, that absence of submission_id indicates no submission, that blocked route links should trigger a user upload request, that conflicting waypoints require user confirmation, and that unconfirmed fields must be omitted rather than guessed. It also discloses return value semantics (job with submission_id and final_crsprof_artifact_id). These are critical behaviors beyond a simple schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite its length, the description is well-structured and front-loaded. The first sentence states the core purpose, followed by sibling differentiation, usage rules, metadata instructions, and exclusions. Each section addresses a distinct need, and the verbose metadata guidance is justified by the tool's complexity. No sentence is wasted; the length is appropriate for the number of edge cases covered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is remarkably complete given the tool's complexity. It covers prerequisites (searching the catalog, official sources), the full pipeline, accepted source formats, blocked-link fallback, conflict resolution, return value semantics, and explicit don'ts. With a rich output schema presumably present, the description still adds necessary context about job progress and artifacts, ensuring the agent understands the entire submission workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, but the description compensates extensively. It provides concrete examples for metadata.event.name vs course ('name='Speedgoat Mountain Races', course='50K''), explicitly warns against putting distance/elevation in the course name, clarifies that location must not include country, and enumerates required event link types. It adds practical field-level guidance that is absent from the schema, greatly enhancing parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear statement: 'Submit an official/trusted course for CourseProfiler catalog review.' It immediately distinguishes itself as 'the only MCP tool that creates a catalog-review submission' and names sibling tools (import_course, enrich_course_waypoints, generate_course_segments, create_race_plan) that do not fulfill this purpose. The verb 'submit' and resource 'course for catalog review' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'Use this only when the user asked to submit/add/update a course in the catalog.' It also provides a strong exclusion: 'Do not call submit_course for normal race-plan creation; create_race_plan does not require catalog submission.' It further details a pipeline order ('Use this after discovering the official route source externally, importing... enriching... applying metadata, and generating segments') and warns against submitting synthetic geometry, making the usage scope very clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CourseProfiler toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Each tool targets a distinct step in the course/race-planning workflow, and descriptions carefully separate concerns like importing, enriching, segmenting, and generating a plan. The main ambiguity is among the multiple get_*_requirements helpers, but their target phases are clear enough to avoid persistent misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (create_, enrich_, export_, generate_, get_, import_, search_, submit_, validate_). There is no mixing of camelCase or inconsistent verb styles, making the API predictable and easy to navigate.

Tool Count4/5

With 16 tools, the server is at the upper edge of the ideal range but each tool serves a distinct purpose in a complex pipeline covering course import, enrichment, segmentation, runner profiling, plan creation, PDF export, validation, and catalog submission. The count feels justified for the domain rather than bloated.

Completeness4/5

The toolset covers the full lifecycle from course discovery/import through enrichment, segmentation, runner profiling, race plan generation, PDF export, and catalog submission. Minor gaps exist, such as lack of artifact list/delete/update tools and no direct race-plan editing, but agents can work around these via get_artifact and get_job.

Resources