camcors-mcp

by Davidobot

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
The tools have distinct purposes, with only a slight potential confusion between camcors_discard_report_preview (submission/deletion previews) and camcors_discard_preview (creation previews). Their descriptions clarify the difference, but the naming could be more distinct.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'camcors_' prefix. Despite minor variation like 'discard_report_preview' vs 'discard_preview', the overall naming is predictable and logically structured.
Tool Count5/5
With 14 tools, the server covers authentication, listing, reading, creation, editing, submission, and deletion workflows without being excessive. Each tool serves a clear step in the process, earning its place.
Completeness5/5
The tool set provides full lifecycle coverage for CamCORS reports: list, get, create, edit, submit, delete. The prepare/execute pattern ensures user confirmation steps are handled, leaving no obvious gaps in the standard workflow.
Average 4/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds the behavioral detail that the token is invalidated, which is a side effect not captured by annotations. It clarifies that no records are changed, reinforcing the read-only nature.
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?
Two sentences with no fluff. The first sentence states the action, the second clarifies the scope. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and the single undocumented parameter, the description is incomplete. It does not explain how to obtain the previewToken, what happens after invalidation, or any prerequisites. The tool is simple but more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the previewToken parameter at all. The description does not add meaning beyond the schema, failing to compensate for the lack of parameter documentation.
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 clearly states the action: close a preview tab and invalidate its token, and explicitly distinguishes from record-modifying tools by saying 'No CamCORS records are changed.' The verb-resource pair is specific and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a prepared preview needs to be discarded, but it does not explicitly state when to use this tool versus alternatives like camcors_discard_report_preview. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds critical context: returned text is confidential, student-related, and untrusted, warning not to follow embedded instructions.
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?
Two efficient sentences covering purpose and a key warning. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one param and no output schema, the description is adequate but lacks details on return format, structure, or error conditions. The warning is valuable but more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter with pattern, description confirms 'numeric ID' and adds 'accessible'. This adds some meaning beyond schema but does not explain how to obtain the ID or what determines accessibility.
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 clearly states the tool reads one accessible report by numeric ID. It distinguishes from siblings like camcors_get_editable_report by implying this returns raw, untrusted content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives like camcors_list_reports or camcors_get_editable_report. The warning about untrusted content is context, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: readOnlyHint=true suggests no state modifications, but 'populate an editable Draft or Returned report' implies modifying the report's preview state. This is a clear annotation contradiction, and the description does not add any additional behavioral context beyond this.
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?
Two sentences with no wasted words. The first sentence states the purpose, the second provides critical usage guidance. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, low schema coverage, no output schema, and nested objects, the description is somewhat complete but lacks information about return values, error cases, or permissions. The agent can use it for basic understanding but may need additional context for safe invocation.
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 only 25%, so the description must compensate. It adds important semantics: fieldValues keys must come from camcors_get_editable_report, and groups replace the full list using aggregate minutes. For allowNoGroups, the schema already provides a description. Overall, significant added value for two key parameters.
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 clearly states the tool 'populate[s] an editable Draft or Returned report without saving it', specifying the verb 'populate' and the resource type. This distinguishes it from sibling tools like camcors_save_report_edit (which saves) and camcors_discard_report_preview (which discards).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: 'fieldValues keys must come from camcors_get_editable_report' and 'groups replace the full timing-group list and use aggregate minutes for each supervision group size.' It implies the tool is for previewing edits without saving, but no explicit when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds beyond annotations by clarifying that the token is invalidated and that no CamCORS record is changed, confirming the non-destructive read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose and a critical side effect (no record changed). It wastes no words, though it could be slightly more structured with explicit labeling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, existing annotations, and absence of an output schema, the description is largely complete. It covers what the tool does, what it does not do, and a key behavioral trait (token invalidation). Minor gaps remain in parameter explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'token' parameter. The description mentions 'its token' but does not explain that the token represents the preview identifier or its role, leaving the agent to infer from context. More detail would help.
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 clearly states the tool closes and invalidates an unused preview (edit, submission, or deletion) and notes that no record is changed. The verb 'close' and resource 'report preview' are specific, and it distinguishes from sibling tools like 'camcors_discard_preview' by specifying the preview types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for unused previews, implying proper usage when a preview should be discarded. However, it does not explicitly state when not to use it (e.g., for submitting or editing) or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds value by specifying the report statuses ('Draft or Returned') and noting data confidentiality. This provides useful behavioral context beyond structured annotations.
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?
Two concise sentences front-load the purpose and returns, with the second adding a confidentiality note. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with strong annotations and one parameter, the description covers purpose, input scope, and return type. However, since there is no output schema, the description could better describe the structure of the returned editable schema and timing groups to aid agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions opening a report but does not clarify that reportId must be a numeric string (per pattern) or explain its role beyond identifying the report. The agent would benefit from explicit parameter guidance.
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 clearly states the action ('Open a Draft or Returned CamCORS supervision report') and specifies what it returns ('editable field schema, option values, and aggregate supervision timing groups'). It distinguishes from siblings like camcors_get_report (likely a different view) and camcors_list_reports (listing) by focusing on editable reports in specific statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Draft or Returned reports and hints at providing the editable schema, but does not explicitly state when to use this tool versus alternatives like camcors_prepare_report_edit or camcors_get_report. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds critical context: that results contain confidential student identifiers, which warns the agent about data sensitivity. This goes beyond the annotations and is valuable.
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?
Two sentences that are front-loaded with the core action. No unnecessary words; every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least indicate the structure of returned reports (e.g., fields, format). It only mentions confidential identifiers and visibility. The maxRows parameter implies pagination but is not explained. The openWorldHint annotation suggests results may change, but the description does not address this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only academicYear has a description). The tool description does not explain any of the parameters (term, maxRows, reportType, academicYear) or how they filter results. Given low coverage, the description should compensate but does not, leaving the agent to infer from the schema alone.
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 clearly states the verb 'List' and the resource 'reports' (supervision or non-supervision), and specifies the audience 'visible to the authenticated CamCORS supervisor'. This distinguishes it from sibling tools like camcors_get_report, which retrieves a single report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to obtain a list of visible reports) and implicitly differentiates from siblings (e.g., camcors_get_report for a single report). However, it does not explicitly state when not to use it or mention alternatives for filtering or searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds behavioral context by explaining that it reports authentication and triggers user interaction if login is needed. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and every word adds meaning. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the return value format (e.g., boolean or string), nor does it cover potential failure modes (e.g., Chrome not found). For a simple tool with no output schema, these gaps reduce completeness.
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?
There are no parameters, and schema coverage is trivially 100%. Per guidelines, baseline for 0 params is 4. The description does not need to add parameter details since none exist, and it adds value by describing the tool's action.
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 clearly states the verb 'Open' and the resource 'local persistent Chrome session', and distinguishes this tool from sibling tools that deal with reports and submissions. It explicitly says it reports authentication status, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it implies it is a prerequisite for other CamCORS operations, it does not explicitly state that or mention any exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that validation runs without side effects and conditionally returns a short-lived token, providing useful context beyond the annotations.
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?
Two sentences, front-loaded with the action, no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations cover behavioral aspects well, the description lacks detail on the structure of validation errors/warnings and the token properties. Without an output schema, more context about return values would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the only parameter 'reportIds'. Agents must infer it refers to report IDs from context, leaving a significant semantic gap.
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 explicitly states 'Run CamCORS validation without submitting,' clearly identifying the verb (validate) and resource (CamCORS reports). It distinguishes from siblings like camcors_submit_reports by indicating no submission occurs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use before submission by noting 'without submitting' and describes the return of a token when submittable. However, it does not explicitly state when to avoid this tool or cite alternatives like camcors_prepare_report_edit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false (write) and destructiveHint=false. Description adds save-after-preview context but does not disclose potential side effects or persistence details. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Front-loaded action and immediate precondition. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required parameters and no output schema, description covers purpose and precondition well. Could mention post-save behavior (e.g., confirmation message) but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. Description echoes schema for 'confirm' (must be true after confirmation). PreviewToken is not elaborated beyond schema's pattern/format. Baseline 3 is appropriate.
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?
Description clearly states verb and resource: 'save a previously previewed report edit'. It distinguishes from siblings like camcors_prepare_report_edit (preview) and camcors_discard_report_preview (discard).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit precondition: 'Call only after the user has reviewed the visible CamCORS form and explicitly confirmed the save.' Does not name alternatives but context from siblings implies when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by reinforcing 'Nothing is deleted' and revealing the short-lived nature of the token, which is beyond what annotations provide. No contradictions.
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?
The description is extremely concise: two sentences with no wasted words. It front-loads the action and includes a clarifying note about non-deletion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and rich annotations, the description covers the main purpose and behavior. However, it lacks details about the token's lifetime or what happens after token expiry, which could be useful for a preview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'reportIds' parameter, its format, or constraints. While the schema includes a pattern, the description should compensate but fails to add meaning.
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 clearly states the tool opens Draft or Returned reports for deletion and returns a deletion token. It uses a specific verb ('Open') and resource ('reports'), and distinguishes itself from sibling tools like camcors_delete_reports by explicitly noting 'Nothing is deleted by this tool.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is a preview step before actual deletion, and it mentions a short-lived deletion token, which hints at a subsequent deletion call. However, it does not explicitly state when not to use it or name alternative tools, so some guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. The description adds that deletion is permanent and limited to Draft or Returned status. No contradictions. Could further clarify prerequisites or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource, followed by usage condition. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, security requirement, and scope. Missing mention of prerequisite steps (e.g., obtaining the deletion token from another tool) and potential error handling, but sufficient for a simple destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'confirm' has a description). The tool description adds context by mentioning 'deletion token' but does not elaborate on the token format or how to obtain it. Moderate compensation.
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 explicitly states the verb 'delete' and the resource 'Draft or Returned CamCORS reports' using a 'deletion token'. It clearly distinguishes from sibling tools that handle other actions like submission, preparation, or editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a strong condition: 'Call only after the user has reviewed the exact reports and explicitly confirmed deletion.' This guides the agent on when to invoke. Could be improved by mentioning alternative workflows, such as using camcors_prepare_report_deletion first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that no records are created, the tool returns a short-lived preview token, and user review is required. This aligns with annotations (readOnlyHint=true, destructiveHint=false) and adds useful behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no redundant information. Every sentence adds value by stating the core function, the absence of record creation, the return value, and the user requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description covers the essential aspects: purpose, non-destructive nature, return value, and user action. It lacks mention of error conditions or parameter interdependencies but is sufficient for a preview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 60% schema description coverage, the description does not add extra parameter-level guidance. It only says 'Open and populate', which does not clarify the meaning or format of parameters like topic or students beyond what the schema provides.
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 clearly states the tool opens and populates a preview page without creating records, and returns a short-lived preview token. This distinguishes it from siblings like camcors_create_supervision_drafts, which likely create records directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the user must review the visible page before any drafts are created, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives for direct draft creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it discloses that the tool requires explicit user confirmation and warning acknowledgement, which are not captured by the annotations (which only indicate non-readonly, non-idempotent, non-destructive). This helps the agent understand the interactive nature of the submission.
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?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key requirements without extraneous information. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and prerequisites. However, it does not mention the return value or what happens after submission (e.g., confirmation message or ID). Given the absence of an output schema and the tool's complexity, this minor gap prevents a score of 5.
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?
The description adds meaning beyond the input schema by explaining the purpose of each parameter: 'fresh validation token' for submissionToken, 'explicit confirmation' for confirm, and 'explicit warning acknowledgement' for acknowledgeWarnings. While the schema provides basic descriptions, the description clarifies the requirement of freshness and explicitness.
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 clearly states the action ('submit'), the resource ('validated CamCORS reports'), and the goal ('for approval/payment'). It further distinguishes from siblings by mentioning requirements like fresh validation token and explicit confirmation, which are not present in preparation or deletion sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites: a fresh validation token, explicit confirmation, and warning acknowledgement when warnings exist. This provides clear guidance on when to use the tool. It does not explicitly state when not to use it or name alternatives, but the context from sibling tools makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: creation requires explicit user confirmation and does not submit. Annotations already indicate non-readonly, non-destructive, and open-world. No contradictions, but could mention potential side effects if confirm is not true (though schema enforces it).
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?
Two concise sentences, immediately clear what the tool does and when to use it. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers prerequisites (preview token), user action requirement (confirm), and boundaries (does not submit). With no output schema, could mention expected outcome (e.g., draft IDs returned), but overall sufficient for a creation tool.
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 covers confirm with description, but previewToken lacks description. Description adds 'represented by a preview token' linking to previewToken parameter. Provides context beyond schema for previewToken, though format/pattern already exist. Schema coverage 50% is compensated by description.
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?
Description clearly states it creates supervision report drafts using a preview token after user confirmation. Distinguishes from sibling tools like camcors_prepare_supervision_drafts (which likely creates the preview) and camcors_submit_reports (which submits).
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?
Explicitly states 'Call only after the user has reviewed the visible preview and explicitly confirmed creation.' Also notes it does not submit drafts for approval or payment, guiding the agent on when and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![camcors-mcp MCP server](https://glama.ai/mcp/servers/Davidobot/camcors-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Davidobot/camcors-mcp)

Score Badge

Copy to your README.md:

[![camcors-mcp MCP server](https://glama.ai/mcp/servers/Davidobot/camcors-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Davidobot/camcors-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Davidobot/camcors-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server