Skip to main content
Glama
Sign In
mguttmann

action1-mcp-server

by mguttmann
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List data sources

action1_list_data_sources
Read-onlyIdempotent

Lists existing Action1 data sources and filters built-in versus custom sources to support report and data-source management.

Instructions

List data sources. Gets a list of existing data sources. To filter out built-in data sources, set the 'builtin'. Perm: manage_data_sources, manage_reports.

Input Schema

NameRequiredDescriptionDefault
builtinNoSpecify if the package is builtin (yes) or custom (no).
verboseNoSkip per-item compactor.
response_formatNoOutput format. Default markdown.

Output Schema

NameRequiredDescriptionDefault
noteNo
countYes
itemsYes
totalNo
truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +{}
    • addedOutput schema / properties / items / items / properties
      Added value: +{
+  "builtin": {},
+  "columns": {},
+  "description": {},
+  "id": {},
+  "language": {},
+  "name": {},
+  "script_text": {},
+  "self": {},
+  "status": {},
+  "type": {}
+}
  2. First observedv0.5.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new behavioral context in the permission requirement (manage_data_sources, manage_reports), which tells the agent an auth precondition exists. It does not cover pagination, result size, or org/tenant scoping, so it stops short of a 4.

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?

Three short sentences with the actionable permission note buried last. The second sentence is pure duplication of the first, which is wasted space in an otherwise tiny definition.

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?

An output schema exists, so return values need not be explained, and all three params are fully documented in the schema; the description supplies the permission requirement, which is the main missing piece. Only result-set scoping/pagination and the relationship to action1_get_data_source remain unaddressed.

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

Parameters3/5

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

Schema description coverage is 100% with three documented parameters, so the baseline of 3 applies. The description only touches 'builtin' and even that awkwardly ("set the 'builtin'" without stating the Yes/No values), and says nothing about verbose or response_format, so it adds no meaning beyond the schema.

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 first sentence states a specific verb and resource (list data sources), and the name plus siblings (get_data_source, create_data_source) make the operation unambiguous. The second sentence, "Gets a list of existing data sources," simply restates the first and adds nothing. It never explicitly contrasts with action1_get_data_source or action1_list_scripts-style siblings, but the intent is still clear.

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?

"To filter out built-in data sources, set the 'builtin'" is parameter guidance, not usage guidance; it does not say when to call this vs. action1_get_data_source or the create/update/delete siblings. The permission note hints at a precondition but no explicit when/when-not or alternative routing is given.

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

Deploy Server

Other Tools