How do I use GoCanvas MCP Server (read-only)?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GoCanvas MCP Server (read-only) list all forms in my account" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

GoCanvas MCP Server (read-only)

by kbates97

Overview Schema Related Servers Score Discussions

Python

GoCanvas MCP Server (read-only)

A minimal Model Context Protocol server that exposes the read-only endpoints of the GoCanvas API v3 as MCP tools. Scope is limited to four areas: Forms, Submissions, Reports, and Reference Data. No create/update/delete operations are exposed.

Tools

Forms

Tool	Endpoint
`list_forms`	`GET /forms`
`get_form`	`GET /forms/{form_id}`
`list_form_assigned_users`	`GET /forms/{form_id}/assigned_users`
`list_form_shared_departments`	`GET /forms/{form_id}/shared_departments`

Submissions

Tool	Endpoint
`list_submissions`	`GET /submissions` (requires `form_id`)
`get_submission`	`GET /submissions/{submission_id}`
`list_submission_revisions`	`GET /submissions/{submission_id}/revisions`
`get_submission_value`	`GET /submissions/{submission_id}/values/{value_id}`

Reports

Tool	Endpoint
`list_form_reports`	`GET /forms/{form_id}/reports`
`get_form_report`	`GET /forms/{form_id}/reports/{report_id}`
`get_submission_default_pdf`	`GET /submissions/{submission_id}/pdf` (PDF)
`get_submission_report_pdf`	`GET /submissions/{submission_id}/reports/{report_id}` (PDF)
`get_submission_standard_pdf`	`GET /submissions/{submission_id}/standard_pdf` (PDF)

The three PDF tools return the binary PDF inline as base64 (content_base64, content_type, size_bytes) — the server is a pure passthrough and never writes to disk, so the tools work on read-only / ephemeral hosts such as AWS Lambda.

Reference Data

Tool	Endpoint
`list_reference_data`	`GET /reference_data`
`get_reference_data`	`GET /reference_data/{reference_data_id}`

Authentication

Tool	Endpoint
`refresh_oauth_token`	`POST /oauth/token` (client-credentials)

refresh_oauth_token forces a fresh bearer token to be fetched and cached. It only applies to server-side OAuth (GOCANVAS_CLIENT_ID / GOCANVAS_CLIENT_SECRET) mode; in passthrough mode the caller owns the token and the server cannot refresh it. It is normally unnecessary — the server fetches a token on startup and refreshes it automatically before expiry and on a 401 — but it is exposed so the agent can rotate the token explicitly. The returned access token is masked.

Related MCP server: N-central MCP Server

Setup

This project uses uv. With uv installed, no manual environment setup is required — uv run resolves and installs dependencies (from pyproject.toml) automatically on first launch.

# optional: pre-create the environment
uv sync

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Configuration

The server is a thin passthrough to the GoCanvas API and starts with no credentials configured. Authentication is resolved per request, in the following priority order:

Source	Description
Incoming `Authorization` header	Forwarded verbatim to the GoCanvas API. This is the passthrough mode used when the server is hosted publicly behind a caller that performs its own OAuth flow (e.g. a Microsoft 365 Copilot custom agent). No server-side credentials are needed.
`GOCANVAS_CLIENT_ID` / `GOCANVAS_CLIENT_SECRET`	OAuth 2.0 client credentials. A short-lived bearer token is fetched from `/oauth/token`, cached, and auto-refreshed on expiry or `401`.
`GOCANVAS_API_TOKEN`	Static bearer token.
`GOCANVAS_USERNAME` / `GOCANVAS_PASSWORD`	HTTP Basic auth (fallback).

Other optional variables:

Variable	Description
`GOCANVAS_OAUTH_SCOPE`	Optional OAuth scope to request (server-side OAuth only).
`GOCANVAS_BASE_URL`	Defaults to `https://api.gocanvas.com/api/v3`.
`GOCANVAS_TIMEOUT`	HTTP timeout in seconds (default `30`).
`GOCANVAS_TRANSPORT`	`stdio` (default), `streamable-http`, or `sse`.
`GOCANVAS_HOST`	Bind host for HTTP transports (default `127.0.0.1`).
`GOCANVAS_PORT`	Bind port for HTTP transports (default `8000`).
`GOCANVAS_STATELESS_HTTP`	No per-session state between requests (default `true`; required for Lambda).
`GOCANVAS_JSON_RESPONSE`	Return JSON instead of an SSE stream (default `true`; required for Lambda).
`GOCANVAS_ALLOWED_HOSTS`	Comma-separated `Host` allow-list for DNS-rebinding protection. Defaults to localhost only, which returns HTTP `421` behind API Gateway / a Function URL — set your public domain or `*` when hosting publicly.
`GOCANVAS_ALLOWED_ORIGINS`	Comma-separated `Origin` allow-list (same semantics).

If no usable credentials are available for a call (no incoming Authorization header and no configured env credentials), the tool returns a clear error — the server itself still starts fine.

Running

Locally over stdio (default)

GOCANVAS_CLIENT_ID=... GOCANVAS_CLIENT_SECRET=... uv run server.py

Publicly over HTTP (e.g. Microsoft 365 Copilot custom agent, AWS Lambda)

Run with an HTTP transport and no GoCanvas credentials — the agent's OAuth bearer token is forwarded per request:

GOCANVAS_TRANSPORT=streamable-http GOCANVAS_HOST=0.0.0.0 GOCANVAS_PORT=8000 uv run server.py

The MCP endpoint is served at /mcp. Point your 365 Copilot custom agent's MCP connection at the public URL and configure its OAuth so it obtains a GoCanvas token; that token is passed through to the GoCanvas API on every tool call. No PDFs or other state are written to disk, so the server runs cleanly on read-only / ephemeral hosts.

Hosting publicly? Set GOCANVAS_ALLOWED_HOSTS to your public domain (or *). The default DNS-rebinding protection allows only localhost and returns HTTP 421 Misdirected Request for any other Host header.

On AWS Lambda

The module exposes an ASGI app (asgi_app()) and a Mangum-wrapped Lambda entry point (lambda_handler), so it runs on Lambda behind an API Gateway HTTP API or a Lambda Function URL with no long-running process. mangum is a declared dependency. Stateless + JSON-response mode is the default (Lambda containers are ephemeral and don't share session state, and API Gateway can't proxy an SSE stream).

A ready-to-deploy AWS SAM template is included (template.yaml); it provisions the function plus a public Function URL:

sam build
sam deploy --guided

The stack outputs the MCP endpoint (<FunctionUrl>/mcp). Point your agent there. Key details baked into the template:

Handler: server.lambda_handler. Runtime: python3.12 (arm64).
AuthType: NONE on the Function URL — required so the caller's Authorization bearer reaches the app for passthrough (AWS_IAM would consume it for SigV4). Auth is enforced at the app layer, not by Lambda.
GOCANVAS_ALLOWED_HOSTS=* so the Function URL's own domain passes the rebinding check. Narrow it to your *.lambda-url.<region>.on.aws (or API Gateway) domain to tighten.
For server-side OAuth instead of passthrough, set GOCANVAS_CLIENT_ID / GOCANVAS_CLIENT_SECRET in the function's environment (prefer Secrets Manager / SSM references over plaintext).

Payload-size limit. API Gateway / a buffered Function URL caps a response at 6 MB. The PDF tools return the file base64-encoded inline (~33% overhead), so a PDF larger than ~4.5 MB can exceed that limit. Raise MemorySize/Timeout for large forms; for consistently large PDFs, front the function with a Function URL in RESPONSE_STREAM invoke mode or fetch the PDF out-of-band.

MCP client configuration

Use uv run as the command. --directory points uv at this project so it uses the right dependencies regardless of the client's working directory:

{
  "mcpServers": {
    "gocanvas": {
      "command": "uv",
      "args": [
        "run",
        "--directory", "/absolute/path/to/GoCanvas",
        "server.py"
      ],
      "env": {
        "GOCANVAS_CLIENT_ID": "your_client_id",
        "GOCANVAS_CLIENT_SECRET": "your_client_secret"
      }
    }
  }
}

If uv isn't on the client's PATH, use its absolute path (e.g. ~/.local/bin/uv) as the command.

{
  "mcpServers": {
    "gocanvas": {
      "command": "/absolute/path/to/GoCanvas/.venv/bin/python",
      "args": ["/absolute/path/to/GoCanvas/server.py"],
      "env": {
        "GOCANVAS_CLIENT_ID": "your_client_id",
        "GOCANVAS_CLIENT_SECRET": "your_client_secret"
      }
    }
  }
}

On Windows the interpreter is at .venv\Scripts\python.exe. Using a bare python will fail with ModuleNotFoundError: httpx because the client does not use your activated shell environment.

Notes

Pagination: list tools accept a page argument. Response pagination headers (link, current-page, page-items, total-count, total-pages) are surfaced under a pagination key in the tool result.
Rate limiting: the server honors 429 Too Many Requests responses, waiting according to the RateLimit-Reset / RateLimit-Remaining headers (or a bounded exponential backoff) before retrying, per GoCanvas best practices.

Available Tools

16 tools

get_formA

Retrieve a single Form (including its full definition) by id.

Args: form_id: The identifier of the Form.

ParametersJSON Schema

Name	Required	Description	Default
`form_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

The description discloses that the tool returns the full definition of a Form, which is a read-only operation. No annotations are provided, but the description sufficiently covers the behavior for a simple retrieval tool. It does not contradict any 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?

The description is extremely concise with two lines and an Args section. Every sentence is necessary and there is 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?

For a simple read-only tool with one parameter and an output schema, the description is complete enough. It states what is retrieved and the parameter needed. It could mention the read-only nature explicitly, but it's implied.

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?

The description includes an Args section explaining the form_id parameter as 'The identifier of the Form', adding meaning beyond the schema's type and title. However, the explanation is minimal and does not specify format or constraints.

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 retrieves a single Form by id and includes its full definition. The verb 'retrieve' and resource 'Form' are specific, and the scope 'including its full definition' distinguishes it from sibling tools like list_forms.

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 retrieving a specific form by id, but does not explicitly mention when to use this tool versus alternatives (e.g., list_forms for listing). No exclusions or prerequisites are provided.

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

get_form_reportB

Retrieve a single Report definition (including its full definition file) for a Form.

Args: form_id: The identifier of the Form. report_id: The identifier of the Report definition.

ParametersJSON Schema

Name	Required	Description	Default
`form_id`	Yes
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It states a read operation but does not disclose permissions, side effects, or behavior such as whether the definition file is large or requires specific access.

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 short and front-loaded with the main purpose. However, it uses Python docstring formatting which is slightly inefficient for an agent.

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 an output schema exists, the description covers the basic purpose but lacks explanation of what 'full definition file' entails. It is minimally complete for a simple retrieval 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%, so the description must add meaning. It only repeats the parameter names without explaining their roles or acceptable values beyond the schema's type and title.

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 uses specific verb 'Retrieve' and resource 'Report definition' and distinguishes from sibling 'list_form_reports' by stating it retrieves a single definition including its full file.

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?

No explicit when-to-use or when-not-to-use guidance is provided. It is implied that this tool is for retrieving a specific report definition, but no alternatives or prerequisites are mentioned.

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

get_reference_dataA

Retrieve a single Reference Data resource by id.

Args: reference_data_id: The identifier of the Reference Data resource.

ParametersJSON Schema

Name	Required	Description	Default
`reference_data_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so the description must cover behavior. It only states the retrieval action without mentioning permissions, error handling, or what happens if the resource is not found.

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 concise with two sentences, but the args documentation format adds a bit of structure. Could be slightly tighter.

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 that an output schema exists, the description does not need to explain return values. It adequately covers the retrieval of a single resource by ID.

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?

The description adds 'The identifier of the Reference Data resource' to the parameter, which adds meaning beyond the schema title. However, schema coverage is 0%, so the description partially compensates.

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 (retrieve), the resource (Reference Data resource), and the method (by id), which distinguishes it from sibling tools like list_reference_data.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., list_reference_data). The context is implied but not stated.

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

get_submissionA

Retrieve a single Submission (including its values) by GUID.

Args: submission_id: The Submission GUID.

ParametersJSON Schema

Name	Required	Description	Default
`submission_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool retrieves a submission and its values, but does not disclose behavioral traits such as authentication requirements, rate limits, or whether it is read-only. The presence of an output schema partially mitigates the need for return format details, but other behavioral aspects are missing.

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 concise, using two sentences with clear intent. The first sentence front-loads the main purpose. However, it could be slightly more structured (e.g., separating usage notes).

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 the tool's simplicity and the presence of an output schema, the description covers the core function. However, it lacks usage guidelines and behavioral transparency, which are needed for a complete understanding. It is adequate but has gaps.

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?

With 0% schema description coverage, the description adds meaning by explaining 'submission_id' as 'The Submission GUID', which is not present in the schema. This compensates for the lack of parameter descriptions in the schema.

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 ('Retrieve'), the resource ('a single Submission including its values'), and the identifier method ('by GUID'). It distinguishes from siblings like 'list_submissions' (multiple submissions) and 'get_submission_value' (single value).

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 needing a full submission by ID, but does not explicitly mention when not to use it or provide alternatives. Context from sibling names suggests distinctions, but the description itself lacks guidance.

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

get_submission_default_pdfC

Download the default Report PDF for a Submission and return its bytes inline as base64.

Args: submission_id: The identifier of the Submission.

ParametersJSON Schema

Name	Required	Description	Default
`submission_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits but only mentions the download action and output format. It does not address permissions, side effects (e.g., whether downloading increments a counter), rate limits, or error conditions. The description is insufficient for full transparency.

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 a single sentence and one parameter line. It is front-loaded with the core purpose and contains no redundant 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?

Given the tool's simplicity (one parameter) and the existence of an output schema, the description covers the basic function and output format. However, it lacks critical context about usage relative to sibling tools (e.g., 'default' vs 'standard' PDF) and does not mention error handling or common use cases, making it incomplete for an agent needing to decide when to invoke it.

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?

The schema has only one parameter with 0% description coverage. The description adds a brief explanation ('The identifier of the Submission'), which provides minimal semantic value beyond the schema's type and title. For a single parameter, this is adequate but not exemplary.

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

Purpose4/5

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

The description clearly states the action ('download') and the resource ('default Report PDF for a Submission'), and specifies the output format ('bytes inline as base64'). However, it does not differentiate from sibling tools like get_submission_report_pdf and get_submission_standard_pdf, which limits clarity on when to use this specific tool.

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 is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, limitations, or when not to use it, leaving the AI agent without context for selection.

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

get_submission_report_pdfB

Generate and download a specific Report PDF for a Submission by Report id.

Args: submission_id: The identifier of the Submission. report_id: The identifier of the Report definition to render.

ParametersJSON Schema

Name	Required	Description	Default
`report_id`	Yes
`submission_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It states 'generate and download' but omits details about output format (binary PDF), potential side effects, or access requirements. The description does not explain whether generating a PDF consumes quotas or requires specific permissions.

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 brief and front-loaded with the core purpose. The Args section is structured but adds redundancy. Overall, it is reasonably concise with minimal 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?

Given the tool has 2 required parameters and an output schema, the description minimally addresses context. It explains what the tool does and its inputs, but lacks guidance on error handling, retrieval of report_id, or output expectations beyond the schema. The output schema exists but the description does not reference it.

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 Args section provides minimal descriptions ('identifier of the Submission/Report definition'), which adds some value beyond the bare schema. However, with 0% schema description coverage, the description does not fully compensate, leaving ambiguity about parameter format, constraints, or how to obtain valid IDs.

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 (generate and download), the resource (Report PDF for a Submission), and the key identifier (Report id). It effectively distinguishes from sibling tools like get_submission_default_pdf and get_submission_standard_pdf which handle different PDF 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 implies usage for specific report PDFs but lacks explicit guidance on when to use this versus sibling tools like get_submission_default_pdf. No when-not or alternative conditions are stated.

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

get_submission_standard_pdfC

Download the Standard Report PDF for a Submission and return its bytes inline as base64.

Args: submission_id: The identifier of the Submission.

ParametersJSON Schema

Name	Required	Description	Default
`submission_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

Describes output format (base64 bytes) but lacks details on size limits, error conditions, or side effects. No annotations provided to augment.

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?

Concise two-sentence description with an args list; no redundant information. Efficiently structured.

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?

With an output schema and a simple download action, the description covers core function and output format. However, lacks usage context and behavioral details that 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 has 0% description coverage; the description restates 'identifier of the Submission' which adds minimal meaning beyond the schema's type and title.

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

Purpose4/5

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

Clearly states it downloads the Standard Report PDF as base64. Distinguishes from 'get_submission_default_pdf' and 'get_submission_report_pdf' by specifying 'Standard Report', though not explicitly contrasted.

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 tool over siblings like 'get_submission_default_pdf' or prerequisites such as submission existence or permissions.

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

get_submission_valueB

Retrieve a single Value from a Submission (e.g. a media field).

Args: submission_id: The Submission GUID. value_id: The identifier of the Value within the Submission.

ParametersJSON Schema

Name	Required	Description	Default
`value_id`	Yes
`submission_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'Retrieve', indicating a read operation, but gives no details on authorization, rate limits, side effects, or what happens if the value does not exist.

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 very concise, consisting of two sentences and a parameter list. The purpose is front-loaded, and every sentence adds value. No redundant or extraneous 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?

Given the tool's simplicity and the presence of an output schema, the description is minimally adequate. It covers the purpose and parameter list but lacks usage guidelines, behavioral details, or examples of when to use this 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%, meaning the parameters have no descriptions in the schema. The description restates parameter names and says 'The Submission GUID' and 'The identifier of the Value within the Submission', adding minimal meaning beyond the names themselves. No format or constraints are specified.

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 uses a specific verb ('Retrieve') and clearly identifies the resource ('a single Value from a Submission'), with an example ('e.g. a media field'). This distinguishes it from sibling tools like get_submission (whole submission) and list_submissions (collection of submissions).

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 the tool is for retrieving a specific value within a submission, but it does not explicitly state when to use it over alternatives like get_submission or list_submissions. No when-not or exclusion criteria are provided.

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

list_form_assigned_usersC

List the Users assigned to a Form.

Args: form_id: The identifier of the Form.

ParametersJSON Schema

Name	Required	Description	Default
`form_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must cover behavioral traits. It only states the action without mentioning authentication, error handling, or limitations, leaving significant gaps.

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 description is brief but under-informative; it adds no value beyond the name. While structured, it sacrifices completeness for brevity.

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?

Even with an output schema handling return values, the description lacks context about ordering, filtering, or edge cases, making it insufficient for a tool with one required parameter.

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 0% schema description coverage and only one parameter (form_id), the description merely restates the parameter name without adding format details or constraints beyond the schema.

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 'List the Users assigned to a Form' with a specific verb and resource, distinguishing it from siblings like list_forms and list_form_shared_departments.

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 is provided on when to use this tool versus alternatives, no when-not-to-use conditions, and no context about prerequisites or scenarios.

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

list_form_reportsB

List the Report definitions associated with a Form.

Args: form_id: The identifier of the Form. page: Optional page number for pagination.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`form_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description only implies a read operation ('List'). It does not disclose any behavioral traits such as authentication requirements, rate limits, or potential 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.

Conciseness4/5

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

The description is concise with one sentence for purpose and a clear arg list. It is well-structured and front-loaded.

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 simplicity and the presence of an output schema, the description adequately covers what the tool does. It does not explain return format but that is handled by the output schema.

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?

The description adds semantic meaning to both parameters (form_id as identifier, page for pagination) beyond the schema's type information. However, schema description coverage is 0%, so while it compensates partially, it is not exhaustive.

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 lists report definitions associated with a form, using a specific verb and resource. It distinguishes from sibling tools like list_forms or get_form which operate on forms directly.

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 tool versus alternatives or when not to use it. The description lacks any context for selection among sibling tools.

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

list_formsB

List all Forms in the company.

Args: page: Optional page number for pagination.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states it lists forms with optional pagination. No mention of permissions, rate limits, whether it's read-only, or what data is returned (e.g., only IDs or full details).

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 concise at one sentence plus a parameter note, with no fluff. However, it is slightly under-specified for a list tool, which could warrant a point deduction.

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 the existence of an output schema (not shown), description does not need to explain return values. However, it lacks details on default sorting, whether pagination is enforced, and scope (e.g., all forms globally or per user). It is minimally adequate for a simple list tool.

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 0% (no descriptions in input schema), but the description adds meaning for the 'page' parameter by stating it is for pagination. However, it does not specify page size, default behavior, or any constraints on the parameter.

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 'List all Forms in the company.', specifying the verb 'list' and the resource 'forms'. This distinguishes it from sibling tools like 'get_form' (single form) and 'list_form_assigned_users' (specific subset).

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. It does not mention context, exclusions, or prerequisites for listing forms vs. other list or get operations.

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

list_form_shared_departmentsC

List the Departments a Form is shared with.

Args: form_id: The identifier of the Form.

ParametersJSON Schema

Name	Required	Description	Default
`form_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic purpose, lacking information on authentication requirements, read-only status, rate limits, or any 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.

Conciseness4/5

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

The description is very concise and front-loaded with the purpose. It uses only necessary words for a simple one-parameter tool. However, it could include more context without sacrificing conciseness.

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?

For a simple tool with an output schema, the description lacks completeness. It does not mention return value format, pagination, error handling, or any security context. The presence of an output schema partially mitigates the need for return value description, but behavioral and usage gaps remain.

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 0% schema description coverage, the description adds minimal value by restating 'form_id: The identifier of the Form.' This does not clarify valid values, format, or how to obtain form IDs, relying entirely on the parameter name and type.

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 'List the Departments a Form is shared with.' It uses a specific verb ('List') and resource ('Departments'), and distinguishes well from siblings like list_forms (lists all forms) and list_form_assigned_users (lists assigned users).

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, such as list_form_assigned_users or get_form. No context about prerequisites or typical use cases is given.

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

list_reference_dataA

List all Reference Data resources in the company.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavioral traits such as read-only nature, authorization requirements, pagination, or performance implications. Only states it lists all resources.

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?

Single sentence with no redundant information. Concise but could be slightly more informative without being verbose.

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?

With no parameters and an output schema available, the description is minimal. It lacks context on potential large dataset, ordering, or scope beyond 'in the company'. Adequate but incomplete.

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?

No parameters in input schema, and schema description coverage is 100%. Baseline for 0 parameters is 4, and description adds no parameter info as none exist.

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 'List' and resource 'Reference Data resources' with scope 'in the company'. Distinguishes from sibling 'get_reference_data' which retrieves a single reference data resource.

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?

Implied usage as a list-all operation due to its name and sibling 'get_reference_data', but no explicit guidance on when to use or not use, or alternatives.

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

list_submission_revisionsC

List the revision history of a Submission.

Args: submission_id: The identifier of the Submission. page: Optional page number for pagination.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`submission_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It identifies the operation as listing (read-only) but does not mention pagination details, ordering, potential errors, or any side effects. The page parameter hints at pagination but lacks specifics like default page size.

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 description is very concise with a single sentence and a bullet list of parameters. It is front-loaded and contains no redundant text. However, the brevity results in missing essential details, making it only minimally adequate.

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 tool has an output schema but the description does not describe what each revision contains, nor does it mention ordering, filtering, or relationships to other tools. The pagination is mentioned but not fully detailed. The description feels incomplete for a list 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%, so the description should compensate. It provides minimal explanations for the two parameters ('identifier of the Submission' and 'optional page number for pagination') but does not clarify how to obtain the submission_id, the default page value, or the maximum page size. This is insufficient for a tool with no schema descriptions.

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

Purpose4/5

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

Clearly states the tool lists revision history of a submission, which distinguishes it from sibling tools like get_submission (current state) or list_submissions (list all submissions). However, lacks detail on what constitutes a revision.

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 tool versus alternatives, no prerequisites, and no context on typical use cases. The description merely states the action without any usage direction.

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

list_submissionsA

List Submissions for a Form.

Args: form_id: Required. The identifier for the Form associated with the Submissions. page: Optional page number for pagination. department_id: Filter by the Department associated with the Submission. user_id: Filter by the User who created the Submission. status: Status filter. One of: all, completed, deleted, in-progress, overdue, rejected, handed-off, assigned, unassigned, custom, saved-to-cloud, unfinished. hand_off: Workflow handoff state name (required when status is "handed-off"). custom_status: Custom status label (required when status is "custom"). start_date: DateTime lower bound for the Submission created_at. end_date: DateTime upper bound for the Submission created_at.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`status`	No
`form_id`	Yes
`user_id`	No
`end_date`	No
`hand_off`	No
`start_date`	No
`custom_status`	No
`department_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description is the sole source of behavioral info. It details parameters and status options but does not disclose pagination behavior, rate limits, or what happens when no results are found. The lack of behavioral context limits transparency.

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 description is structured as an Args list but is somewhat verbose with repeated 'Optional' and 'Filter' phrasing. It could be more concise by grouping optional filters, but it remains readable.

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 has 9 parameters and no annotations, the description covers all parameters with explanations. The presence of an output schema means return values don't need elaboration. It is reasonably complete for a listing 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 description coverage is 0%, so the description must add meaning. It explains each parameter, including that form_id is required, page is for pagination, and clarifies conditional requirements for hand_off and custom_status based on status. This adds significant value beyond the raw schema.

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 'List Submissions for a Form,' which is a specific verb+resource. This distinguishes it from sibling tools like list_forms, get_submission, etc., which have different purposes.

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 lists parameters but does not explicitly state when to use this tool versus alternatives like get_submission or list_submission_revisions. No guidance on when not to use or prerequisites is provided.

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

refresh_oauth_tokenA

Fetch a fresh OAuth bearer token from /oauth/token (client-credentials grant).

Requires GOCANVAS_CLIENT_ID and GOCANVAS_CLIENT_SECRET to be configured. The token is cached and used automatically for subsequent API calls; call this to force a refresh (e.g. after a 401). Returns token metadata with the access token masked for safety.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior4/5

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

No annotations provided, but description discloses caching behavior, automatic usage, and safety masking of token. Could mention error handling if credentials missing, but still strong.

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?

Three tight sentences, each earning its place. Front-loaded with core action. Zero fluff.

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?

Covers all needed context for a zero-parameter tool: what it does, when to use, prerequisites, return format, and caching. Output schema exists but description adds context.

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?

No parameters, schema coverage 100%. Description adds value by explaining the purpose of the tool beyond the empty schema.

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 explicitly states it fetches a fresh OAuth bearer token using client-credentials grant, which clearly distinguishes it from sibling tools that handle forms and submissions.

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?

Provides explicit when to use (after a 401, force refresh) and prerequisites (GOCANVAS_CLIENT_ID and GOCANVAS_CLIENT_SECRET). No ambiguity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesv0.1.0Jul 28, 2026
- First observedget_form
- First observedget_form_report
- First observedget_reference_data
- First observedget_submission
- First observedget_submission_default_pdf
- First observedget_submission_report_pdf
- First observedget_submission_standard_pdf
- First observedget_submission_value
- First observedlist_form_assigned_users
- First observedlist_form_reports
- First observedlist_form_shared_departments
- First observedlist_forms
- First observedlist_reference_data
- First observedlist_submission_revisions
- First observedlist_submissions
- First observedrefresh_oauth_token

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct resource or operation: forms, submissions, reference data, PDFs, and OAuth. No overlapping purposes; descriptions clearly differentiate.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., list_forms, get_submission). No deviations or mixed conventions.

Tool Count5/5

16 tools cover the read-only surface of forms, submissions, reports, reference data, and PDFs. The count is well-scoped for the server's purpose.

Completeness5/5

The tool set provides full read coverage for the domain: listing and getting forms, submissions, reports, reference data, plus PDF downloads. No obvious gaps remain.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

DATPAQ
com.datpaq
34 production API tools over one hosted MCP endpoint.
Developer Tools
2
OneOAuth
ai.withone
Search, document and execute authenticated API calls across 700+ apps via one MCP server
API Testing App Automation
110
climbpast
io.github.archievi
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Marketing Search Data Platforms
1
Deooch FormsOAuth
io.github.musaib001
Create forms, manage submissions, and export responses from your MCP client.
Workplace & Productivity App Automation
2

Related MCP Servers

JustOneAPI MCP Serverofficial
Search Social Media
justoneapi
A
license
A
quality
A
maintenance
Exposes JustOneAPI endpoints as MCP tools, returning raw upstream JSON without field parsing for maximum data fidelity.
Updated 12 days ago (2026-08-25 10:43 UTC)
7
21
30
MIT
N-central MCP Server
Monitoring Networking & Infrastructure
theonlytruebigmac
A
license
B
quality
C
maintenance
Exposes N-able N-central REST API as MCP tools for managing devices, organizations, users, and more, with support for read-only, write, and full write modes.
Updated a month ago (2026-08-01 06:15 UTC)
82
5
MIT
Filly Forms MCP Server
eneopt
A
license
Not graded
quality
C
maintenance
Exposes the Filly Forms REST API as MCP tools for AI agents, enabling form type listing, record CRUD, data preview, and document upload with AI extraction.
Updated 2 months ago (2026-07-21 13:37 UTC)
MIT
cloudradial-mcp
CRM Customer Support
MSPbotsAI
F
license
Not graded
quality
B
maintenance
Exposes the CloudRadial REST API (client portal / PSA-adjacent MSP platform) as MCP tools, enabling operations on companies, articles, feedback, archives, flexible assets, and more via 34 tools with HTTP Basic Auth.
Updated 3 days ago (2026-09-04 02:54 UTC)
-

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/kbates97/GoCanvas-Readonly-MCP'

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

GoCanvas MCP Server (read-only)

Tools

Forms

Submissions

Reports

Reference Data

Authentication

Setup

Configuration

Running

Locally over stdio (default)

Publicly over HTTP (e.g. Microsoft 365 Copilot custom agent, AWS Lambda)

On AWS Lambda

MCP client configuration

Notes

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

JustOneAPI MCP Serverofficial

Latest Blog Posts

MCP directory API