Skip to main content
Glama
Sign In

Compoid MCP

by com.compoid
OverviewDiscussionsAdmin

Compoid_create_record

Create a new Compoid record and submit it to a community for review.

Required:
    file_upload: the file to attach. Accepted: (1) a data URI
        'data:<mime>;base64,<b64>' (base64-encode client-side files), or (2) a
        path on the MCP server host such as '/projects/...' (e.g. the path
        returned by Compoid_upload_file). Plain client-local paths are NOT
        accessible to the server.
    creators: non-empty list of author / AI-model names (e.g.
        ['John Doe']); for AI-generated content include the model name
        as a co-creator (e.g. ['Qwen']).
    keywords: non-empty list of tags (e.g. ['Compoid', 'MCP']) - records
        without keywords are hard to discover.

Recommended (thin records are hard to discover and may be rejected):
    title, description: a clear title and abstract.
    resource_type: one of analysis, image, video, audio, publication, document,
        software, project, dataset, presentation, workflow, tutorial, event, crypto, forex, indices,
        equities, physicalobject, model, other -
        any other value is rejected with 400 'Not a valid value.' (when omitted
        it is inferred from the file MIME type).
    subjects: up to 5 subject display names from the Compoid subject vocabulary
        (https://www.compoid.com/subjects); invalid names cause a 400.
        "Artificial Intelligence" is always appended as a default subject.

Optional:
    community_id: community slug (e.g. 'physics' - browse
        https://www.compoid.com/communities or use Compoid_search_communities),
        a community UUID, or a home-community slug 'user-<id>'. When omitted,
        the record is submitted to the API token's own home community
        (resolved via Compoid_whoami).

Input Schema

NameRequiredDescriptionDefault
titleNo
creatorsYes
keywordsYes
subjectsNo
referencesNo
descriptionNo
file_uploadYes
community_idNo
resource_typeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / community_id / default
      Added value: +null
    • changedInput schema / required
      Previous value: -[
-  "community_id",
-  "file_upload",
-  "creators",
-  "keywords"
-]New value: +[
+  "file_upload",
+  "creators",
+  "keywords"
+]
  2. Changed2 schema fields changed
    • removedInput schema / properties / keywords / default
      Removed value: -null
    • changedInput schema / required
      Previous value: -[
-  "community_id",
-  "file_upload",
-  "creators"
-]New value: +[
+  "community_id",
+  "file_upload",
+  "creators",
+  "keywords"
+]
  3. Changed1 schema field changed
    • addedInput schema / properties / subjects
      Added value: +{
+  "default": null,
+  "items": {
+    "type": "string"
+  },
+  "title": "Subjects",
+  "type": "array"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover the generic write/open-world profile; the description goes well beyond by disclosing concrete side effects and failure modes: invalid resource_type or subjects produce 400s, 'Artificial Intelligence' is always appended, records without keywords are hard to discover, and client-local paths are not reachable by the server. That is substantive behavioral context an agent cannot get from the structured fields.

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

Conciseness4/5

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

Long, but deliberately structured under Required/Recommended/Optional headings with the action statement front-loaded, and each block maps to a distinct decision the caller must make. A few lines (e.g. repeated discovery warnings) restate the same point, which is the only slack.

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 9 parameters, an output schema, and an open-world write operation, the description supplies formats, defaults, validation rules, and error codes — everything needed to invoke it correctly except the undocumented `references` parameter and any explicit auth/token prerequisite. Otherwise complete for this complexity.

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 coverage is 0%, so the description carries the full burden and mostly delivers: file_upload formats (data URI vs server path), creators/keywords list semantics, the full resource_type vocabulary with rejection behavior, subjects limit and vocabulary URL, and community_id accepted forms (slug/UUID/home slug) plus the default. The only gap is `references`, which appears in the schema but is never explained.

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?

Opens with a specific verb+resource ('Create a new Compoid record') and adds the distinctive outcome ('submit it to a community for review'), which cleanly separates it from Compoid_update_record, Compoid_delete_record, and Compoid_create_community. An agent can identify the operation without reading the 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?

Explicitly routes to alternatives: use Compoid_upload_file's returned path for file_upload, Compoid_search_communities or the communities URL to pick a community_id, and Compoid_whoami to resolve the default home community when community_id is omitted. It also states when fields are required vs recommended and why thin records fail, leaving nothing to inference.

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

All Compoid MCP toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources