Skip to main content
Glama
Sign In

TaScan

by io.github.snowbikemike
OverviewDiscussionsAdmin

tascan_list_projects

Read-onlyIdempotent

List TaScan projects in the organization (each with its number, e.g. P-00001, external_refs, report_options and its calendar_url, webcal_url, map_url and wallet_pass_url). Optional filters: status (exact, comma list), number (exact), ref (matches any external_refs[].ref exactly, e.g. a customer job number like P14-4680), and the portal's date filters: starts_after / ends_before (YYYY-MM-DD) and window (week = Sunday-Saturday, or month) on the project's start/end dates (one date = that day; none = its created day), in zone (an IANA zone; default the org time zone, else UTC).

Input Schema

NameRequiredDescriptionDefault
refNoOnly projects whose external_refs carry this ref (exact, e.g. P14-4680)
zoneNoIANA time zone for the date filters, e.g. America/Los_Angeles (default: the org time zone)
numberNoOnly the project with this project number (exact, e.g. P-00012)
statusNoOnly projects with this status (exact; comma-separated list allowed, e.g. "active,archived")
windowNoOnly projects overlapping this week (Sunday-Saturday) or this calendar month
ends_beforeNoYYYY-MM-DD: only projects whose dates end before this day
starts_afterNoYYYY-MM-DD: only projects whose dates start after this day

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / ends_before
      Added value: +{
+  "description": "YYYY-MM-DD: only projects whose dates end before this day",
+  "type": "string"
+}
    • addedInput schema / properties / starts_after
      Added value: +{
+  "description": "YYYY-MM-DD: only projects whose dates start after this day",
+  "type": "string"
+}
    • addedInput schema / properties / window
      Added value: +{
+  "description": "Only projects overlapping this week (Sunday-Saturday) or this calendar month",
+  "enum": [
+    "week",
+    "month"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / zone
      Added value: +{
+  "description": "IANA time zone for the date filters, e.g. America/Los_Angeles (default: the org time zone)",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / number
      Added value: +{
+  "description": "Only the project with this project number (exact, e.g. P-00012)",
+  "type": "string"
+}
    • addedInput schema / properties / ref
      Added value: +{
+  "description": "Only projects whose external_refs carry this ref (exact, e.g. P14-4680)",
+  "type": "string"
+}
    • addedInput schema / properties / status
      Added value: +{
+  "description": "Only projects with this status (exact; comma-separated list allowed, e.g. \"active,archived\")",
+  "type": "string"
+}
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context: the default time zone behavior (org zone, else UTC), how a single date is interpreted ('one date = that day; none = its created day'), and the URL fields that come back.

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?

It is a single very long run-on sentence packed with parentheticals, including URL fields the agent may not need up front. The core purpose is front-loaded, but the density and the returned-field laundry list reduce scannability.

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?

There is no output schema, so describing returned fields and filter semantics is genuinely necessary and mostly done. Only pagination/result-limit behavior and default ordering are unaddressed, leaving a minor gap for a list 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 coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining interacting semantics — window as Sunday-Saturday week or calendar month, and the one-date/none-date fallback for start/end filters — which the schema does not state.

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 opens with a specific verb and resource ('List TaScan projects in the organization') and enumerates what each record carries (number, external_refs, report_options, calendar/webcal/map/wallet URLs), so the agent knows exactly what it gets back. It is clearly distinct from tascan_get_project (single) and tascan_find.

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?

It spells out the meaning of each filter (exact status comma list, exact number, exact ref against external_refs, date window semantics), which implies when the tool is appropriate. However, it never says when to prefer this over tascan_get_project or tascan_find, nor are there explicit exclusions.

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

All TaScan toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources