Skip to main content
Glama
Sign In
anythink-cloud

Anythink-MCP

Official
by anythink-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Fetch

fetch
Destructive

Send authenticated API requests to any endpoint in the active Anythink project using CLI credentials and print the response. Use it when no dedicated tool exists; POST, PUT, and DELETE alter data.

Instructions

Make an authenticated API request to the active project. Sends a request to any project endpoint, with the path relative to /org/{project}, using the CLI's credentials, and prints the response body. Use it only where no dedicated tool exists, such as /permissions or integration field options; POST, PUT and DELETE change data. all follows every page of a GET. It changes or deletes existing data, so check with the user before running it.

Input Schema

NameRequiredDescriptionDefault
allNoFollow every page of a paged GET response, printing each page as it arrives
bodyNoRequest body (JSON string)
pathYesAPI path (e.g. /integrations/definitions/slack)
methodNoHTTP method (default: GET)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.37
    • addedInput schema / properties / all
      Added value: +{
+  "description": "Follow every page of a paged GET response, printing each page as it arrives",
+  "type": "boolean"
+}
  2. Addedv0.2.27

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the 'changes or deletes existing data' line is partly redundant. The description still adds real value beyond the annotations: which HTTP methods mutate (POST/PUT/DELETE), that credentials come from the CLI, that `all` paginates a GET, and that it prints the response body.

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?

Dense and front-loaded: purpose first, then the fallback rule, then method semantics and the safety check. Most sentences earn their place; the mutation warning is slightly restated by the final sentence, but the length is justified for a catch-all tool.

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?

For a generic HTTP tool with no output schema, the description covers auth source, path resolution, method semantics, pagination behavior, and the return behavior (prints body). An agent has everything needed to invoke it correctly, and the absence of an output schema is compensated for.

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 the baseline is 3, but the description compensates with meaning the schema lacks: the path is resolved relative to /org/{project}, and `all` is scoped specifically to GET pagination. The method-mutation mapping adds cross-parameter semantics not stated per-field 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?

States a specific verb (make/send an authenticated API request) and resource (any project endpoint, path relative to /org/{project}), plus what it produces (prints the response body). It also distinguishes itself from the ~140 specific siblings by framing itself as the generic escape hatch used only when no dedicated tool exists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use it only where no dedicated tool exists' and gives concrete examples (/permissions, integration field options), which is an unusually clear when-to-use-vs-alternatives rule against a large sibling set. It adds a confirmation prerequisite ('check with the user') for mutating methods.

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