Skip to main content
Glama

CourseProfiler

by com.courseprofiler
OverviewDiscussionsAdmin

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / metadata / properties / event / description
      Previous value: -"Important catalog metadata collected from official sources. Populate known fields such as name/event_name, course, year/date, time (race start time), location/city/region/country, distance, elevation_gain, organizer/series, website, official_source_url, types, competitions, and links. metadata.event.name is the main event name and metadata.event.course is the specific course name (for example name='Speedgoat Mountain Races', course='50K'); do not put distance/elevation stats in the course name (bad: 'Skyrace — 32 km, +2400 m'). metadata.event.location must not include country because metadata.event.country is separate. Add metadata.event.types tags when officially applicable (for example race/trail/ultra), and add metadata.event.competitions when the race belongs to a circuit/series/championship, e.g. Golden Trail World Series (GTWS). Do not invent unknown values; omit or leave null when not confirmed. For event-level links, use links with type/url/tooltip entries for General Information (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)."New value: +"Submission metadata is normalized into canonical CRSProf event fields. Supplemental fields (including year, official distance/elevation, notes, and unrecognized extensions) are retained as sourceMetadata in the submission record, not inserted into CRSProf geometry. A year alone does not invent a date; website/source URLs become event links. Important catalog metadata collected from official sources. Populate known fields such as name/event_name, course, year/date, time (race start time), location/city/region/country, distance, elevation_gain, organizer/series, website, official_source_url, types, competitions, and links. metadata.event.name is the main event name and metadata.event.course is the specific course name (for example name='Speedgoat Mountain Races', course='50K'); do not put distance/elevation stats in the course name (bad: 'Skyrace — 32 km, +2400 m'). metadata.event.location must not include country because metadata.event.country is separate. Add metadata.event.types tags when officially applicable (for example race/trail/ultra), and add metadata.event.competitions when the race belongs to a circuit/series/championship, e.g. Golden Trail World Series (GTWS). Do not invent unknown values; omit or leave null when not confirmed. For event-level links, use links with type/url/tooltip entries for General Information (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)."
    • addedInput schema / properties / metadata / properties / event / properties / notes
      Added value: +{
+  "description": "Official caveats or contextual notes retained as submission provenance, not course geometry.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedOutput schema / properties / result_artifacts / items / properties / download_url / description
      Previous value: -"Private short-lived download URL. Share only with the user."New value: +"Artifact download URLs are private and short-lived; share them only with the user, verbatim in a code block, not a clickable link. Ask the user to copy the entire URL into their browser address bar. Do not rewrite the URL or add tracking parameters such as utm_source: changes invalidate the signature. If expired, call get_artifact for a fresh URL. This applies only to artifact download_url values, not authorization or upload links."
  3. Changed3 schema fields changed
    • changedInput schema / properties / course / properties / import_options / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / properties / course / properties / import_options / properties
      Added value: +{
+  "include_routes": {
+    "description": "Include routes when analysing GPX/FIT. Existing CRSProf is preserved with analysis_options_not_applied warning.",
+    "type": "boolean"
+  },
+  "include_segments": {
+    "description": "Generate segments when analysing GPX/FIT. Existing CRSProf is preserved with analysis_options_not_applied warning.",
+    "type": "boolean"
+  }
+}
    • addedInput schema / properties / course / properties / import_options / required
      Added value: +[]
  4. Changed1 schema field changed
    • changedInput schema / properties / course / properties / waypoints / properties / items / items / properties / resources / items / enum
      Previous value: -[
-  "water",
-  "water_source",
-  "drinks",
-  "fruit",
-  "food",
-  "toilet",
-  "medic",
-  "chrono",
-  "crew",
-  "pacer",
-  "car",
-  "bus",
-  "ambulance",
-  "shuttle",
-  "drop_bag",
-  "withdrawal",
-  "binoculars",
-  "hot_meal",
-  "tent",
-  "showers",
-  "changing_room",
-  "physiotherapy",
-  "rest_area",
-  "start_flag",
-  "finish_flag"
-]New value: +[
+  "water",
+  "water_source",
+  "drinks",
+  "fruit",
+  "food",
+  "toilet",
+  "medic",
+  "chrono",
+  "crew",
+  "pacer",
+  "car",
+  "bus",
+  "ambulance",
+  "shuttle",
+  "telecabine",
+  "drop_bag",
+  "withdrawal",
+  "binoculars",
+  "hot_meal",
+  "tent",
+  "showers",
+  "changing_room",
+  "physiotherapy",
+  "rest_area",
+  "start_flag",
+  "finish_flag"
+]
  5. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations supply the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the description needn't restate them. It adds genuinely valuable behavior: the returned job carries submission_id and final_crsprof_artifact_id, absence of submission_id means the course was not submitted, metadata is normalized into canonical CRSProf event fields while supplemental fields become sourceMetadata, and synthetic geometry is rejected. Some of this behavioral detail (metadata normalization) is also carried in the schema, which keeps it from a clean 5.

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

Conciseness3/5

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

The purpose and sibling routing are front-loaded, which is good, but the body is extremely long and repeats substantial metadata-field guidance that also appears near-verbatim in the schema's metadata.event description (name/course conventions, country separation, link types, competition tags). Valuable content is padded by that overlap, so it is not tight.

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?

For a complex, multi-artifact, metadata-heavy submission tool, the description covers the full pipeline, failure modes, evidence requirements, anti-fabrication rules, and the return contract. An output schema exists, so return-value coverage is a bonus rather than a necessity, and nothing an agent needs to invoke this correctly is missing.

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

Parameters4/5

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

Schema description coverage is 50%, so the description must compensate, and it does: it defines naming conventions the schema alone doesn't enforce (metadata.event.name is the event, metadata.event.course is the variant, no distance/elevation stats in the course name, location must exclude country, links belong in metadata.event.links not only source_urls). The guidance is concrete and example-driven, though some is duplicated verbatim in the schema's own descriptions.

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?

States a specific verb and resource ('Submit an official/trusted course for CourseProfiler catalog review') and explicitly distinguishes itself from siblings: import_course, enrich_course_waypoints, and generate_course_segments 'only create temporary artifacts,' and create_race_plan 'does not require catalog submission.' An agent can identify the tool's unique role without opening any schema.

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?

Gives explicit when-to-use ('only when the user asked to submit/add/update a course in the catalog'), when-not ('Do not call submit_course for normal race-plan creation'), prerequisites (search catalog first, import real GPX/FIT/CRSProf, enrich, apply metadata, generate segments), and a fallback ('If route links are blocked, stop and ask the user to upload'). Nothing about selection is left to inference.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources