What can you do with this server?

This is a read-only MCP server for the GoCanvas API v3, letting you retrieve forms, submissions, reports, PDFs, and reference data without any create/update/delete operations. * Forms: list forms, get a form’s full definition, list assigned users, and list shared departments. * Submissions: list submissions (with filters for status, department, user, dates, and pagination), get a submission’s details and values, list revision history, and fetch individual submission values. * Reports: list report definitions for a form, get a specific report definition, and download submission PDFs (default, specific report, and standard) as inline base64. * Reference Data: list all reference data resources and retrieve a single reference data resource by ID. * Authentication: refresh the OAuth bearer token explicitly when using server-side client-credentials mode. * Pagination: list tools accept a page argument and return pagination metadata in results.

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

1. Click on "Deploy 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 Source Related Servers Discussions Admin

Python

Remote

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

There are two independent authentication hops, and they use different credentials on purpose.

Hop 1 — caller to this server

Under an HTTP transport, every request must present a shared secret in the MCP_GATEWAY_HEADER header (default x-mcp-key). Anything else gets 401. This is what keeps a public endpoint from being usable by the public.

Variable	Description
`MCP_GATEWAY_KEYS`	Comma-separated list of accepted secrets. A list rather than one value so keys rotate with no downtime: add the new key, repoint the caller, drop the old. Generate with `openssl rand -base64 32`.
`MCP_GATEWAY_HEADER`	Header the secret is read from (default `x-mcp-key`). Never set this to `Authorization` — that header feeds the GoCanvas passthrough path, so reusing it would forward your gateway secret upstream to the GoCanvas API.
`GOCANVAS_REQUIRE_GATEWAY_KEY`	Default `true`. With no keys configured the endpoint returns `503` rather than serving openly. Set `false` only for local development bound to loopback.

stdio is unaffected — the check only applies to the HTTP transports.

Hop 2 — this server to the GoCanvas API

Resolved per request, in priority order:

Source	Description
Incoming `Authorization` header	Forwarded verbatim. Only when `GOCANVAS_ALLOW_PASSTHROUGH=true`, which is off by default — otherwise a caller could override the server's own credentials, and any bearer they send would be relayed to a third party.
`GOCANVAS_CLIENT_ID` / `GOCANVAS_CLIENT_SECRET`	OAuth 2.0 client credentials. A short-lived bearer is fetched from `/oauth/token`, cached, and auto-refreshed on expiry or `401`. The recommended mode for hosted use.
`GOCANVAS_API_TOKEN`	Static bearer token.
`GOCANVAS_USERNAME` / `GOCANVAS_PASSWORD`	HTTP Basic auth (fallback).

Secrets Manager

For hosted deployments, keep both hops' credentials in one secret instead of in environment variables:

Variable	Description
`GOCANVAS_SECRET_ID`	Name or ARN of a Secrets Manager secret whose JSON body may hold `client_id`, `client_secret`, `scope`, `gateway_keys`. Read once per process (per Lambda container) and cached; takes priority over the equivalent environment variables.
`GOCANVAS_SECRET_REGION`	Defaults to `AWS_REGION`.

A failure to read the secret is logged and falls back to the environment variables rather than crashing the server.

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, 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

Run with an HTTP transport and a gateway key:

GOCANVAS_TRANSPORT=streamable-http GOCANVAS_HOST=0.0.0.0 GOCANVAS_PORT=8000 \
MCP_GATEWAY_KEYS="$(openssl rand -base64 32)" \
GOCANVAS_CLIENT_ID=... GOCANVAS_CLIENT_SECRET=... \
uv run server.py

The MCP endpoint is served at /mcp. 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.

Deploying to 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 a Lambda Function URL or an API Gateway HTTP API with no long-running process. 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).

template.yaml is a complete AWS SAM stack: the function, a Function URL, a Secrets Manager secret, a log group with retention, and a concurrency cap.

Prerequisites

An AWS account and the AWS CLI, configured (aws configure) with permission to create Lambda functions, IAM roles, secrets, and log groups.
The SAM CLI (brew install aws-sam-cli on macOS).
GoCanvas API client ID and secret for a service account, from the GoCanvas admin console.

1. Build and deploy

sam build

The function uses BuildMethod: makefile, so this runs the build-GoCanvasMcpFunction target in Makefile rather than SAM's default Python builder. Two reasons: the default builder copies the entire CodeUri directory, which here would ship the 49 MB local .venv and the OpenAPI specs; and the Makefile pins --platform manylinux2014_aarch64 --python-version 3.12 --only-binary=:all: so the correct Linux/arm64 wheels are installed even when you build from macOS. No Docker or --use-container needed. If you change Runtime or Architectures in the template, update those flags to match.

Then deploy:

sam deploy --guided

Accept the defaults, except: answer yes to GoCanvasMcpFunction Function URL may not have authorization defined, Is this okay? — AuthType: NONE is required because no MCP client can produce a SigV4 signature. The gateway-key check inside the function is the access control.

Subsequent deploys are just sam build && sam deploy.

Note the stack outputs — McpEndpoint, SecretArn, GatewayHeaderName:

aws cloudformation describe-stacks --stack-name gocanvas-mcp \
  --query 'Stacks[0].Outputs' --output table

2. Populate the secret

The stack creates the secret itself but deliberately gives it no value — the value is not a template-managed property, so that a later stack update can never reassert a placeholder over your live credentials. Until you run the command below, the endpoint returns 503 and each cold start logs a warning naming this step.

Use put-secret-value, not create-secret: the secret already exists by this point, so create-secret fails with ResourceExistsException. The same command is also how you rotate later. Generate a gateway key and write both sets of credentials in one shot:

GATEWAY_KEY="$(openssl rand -base64 32)"
echo "Gateway key (save this, you will paste it into Copilot Studio): $GATEWAY_KEY"

aws secretsmanager put-secret-value \
  --secret-id gocanvas-mcp/config \
  --secret-string "$(jq -n \
      --arg cid   "YOUR_GOCANVAS_CLIENT_ID" \
      --arg csec  "YOUR_GOCANVAS_CLIENT_SECRET" \
      --arg key   "$GATEWAY_KEY" \
      '{client_id:$cid, client_secret:$csec, gateway_keys:[$key]}')"

Because the secret is cached per Lambda container, changes take effect on the next cold start. To apply immediately, force new containers:

aws lambda update-function-configuration --function-name gocanvas-mcp \
  --description "secret rotated $(date -u +%FT%TZ)"

3. Verify

Without the key — expect 401:

curl -s -o /dev/null -w '%{http_code}\n' -X POST "$MCP_ENDPOINT" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'

With the key — expect 200 and a serverInfo block:

curl -s -X POST "$MCP_ENDPOINT" \
  -H "x-mcp-key: $GATEWAY_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'

If you get 421 Misdirected Request, GOCANVAS_ALLOWED_HOSTS does not include the Function URL host. If you get 503 server not configured, the secret has no gateway_keys (or the function can't read it — check CloudWatch).

4. Tighten the host allow-list

The Function URL hostname isn't known until the stack exists, so the template bootstraps with AllowedHosts: "*". Once deployed, pin it:

sam deploy --parameter-overrides \
  "AllowedHosts=abc123xyz.lambda-url.us-east-1.on.aws"

Connecting Copilot Studio

Copilot Studio reaches an MCP server through a Power Platform custom connector. Its OAuth path is authorization-code-on-behalf-of-user (the PKCE flow GoCanvas doesn't play well with), and it would make each end user sign in — neither of which is what you want here. Use API Key auth instead, which gives the agent a standing credential:

Create the connector. In Copilot Studio, Tools → Add a tool → New tool → Model Context Protocol, or import an OpenAPI definition carrying x-ms-agentic-protocol: mcp-streamable-1.0. Host = your Function URL hostname, base path = /mcp.
Security tab. Authentication type API Key; parameter label anything; parameter name x-mcp-key; location Header.
Create the connection once, pasting the gateway key from step 2 above.
Set the tool to use the maker/author-provided connection, not end-user credentials. This is what makes the agent's access standing — no per-user sign-in prompt, and the agent works for every user of the published agent.

What this trades away

Every Copilot Studio user now acts as one GoCanvas service account. GoCanvas can no longer enforce per-user authorization, because it only ever sees that account. The tools here are read-only, which bounds the blast radius, but scope the service account's GoCanvas permissions to the minimum set of forms and data the agent should ever surface. "The agent won't ask for it" is not a control.

Hardening beyond the key

WAF IP allow-list. Front the Function URL with CloudFront + AWS WAF and allow only the published Power Platform outbound IP ranges for your region. Treat this as defense in depth, not a primary control: the ranges are shared across all Power Platform tenants and they change, so you have to track the published list. The value is that a leaked key alone stops being enough.
Concurrency cap. ReservedConcurrency (default 10) bounds what a leaked key can cost you and keeps it from exhausting your GoCanvas rate limit.
Watch the rejections. Failed gateway checks log at WARNING to /aws/lambda/gocanvas-mcp. A metric filter on Rejected MCP request plus an alarm turns a leaked or probed endpoint into a page.

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.
Warm Lambda containers: lambda_handler rebuilds the ASGI app on each invocation. Mangum runs the ASGI lifespan per invocation and StreamableHTTPSessionManager.run() raises if entered twice, so a cached app would make every request after a container's first one fail. Rebuilding costs a route table per request and is free of correctness cost in stateless mode.
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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-28 04:40 across 16 tools

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

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
CryptoCultCurt-appfolio-mcp-serverOAuth
ai.smithery
Provide seamless access to Appfolio Property Manager Reporting API through a standardized MCP serv…
Real Estate Databases API Testing
29

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 a month ago (2026-08-25 10:43 UTC)
7
21 npm
30
MIT
N-central MCP Server
Monitoring Networking & Infrastructure
theonlytruebigmac
A
license
A
quality
A
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 3 days ago (2026-09-18 06:13 UTC)
12
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 17 days ago (2026-09-04 02:54 UTC)
-

GoCanvas MCP Server (read-only)

Tools

Forms

Submissions

Reports

Reference Data

Authentication

Setup

Configuration

Hop 1 — caller to this server

Hop 2 — this server to the GoCanvas API

Secrets Manager

Other optional variables

Running

Locally over stdio (default)

Publicly over HTTP

Deploying to AWS Lambda

Prerequisites

1. Build and deploy

2. Populate the secret

3. Verify

4. Tighten the host allow-list

Connecting Copilot Studio

What this trades away

Hardening beyond the key

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

Related MCP Connectors

Related MCP Servers

JustOneAPI MCP Serverofficial