Skip to main content
Glama
Sign In
Local MCP

Local MCP

by colibird-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

twilio_api_request

Calls any Twilio REST API endpoint not covered by other Twilio tools, including Conversations, Studio, and Task resources.

Instructions

(Beta) Any call of Twilio's REST API, for what the twilio_* tools do not cover (Conversations, Studio, Task...

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "twilio_api_request"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.446

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description adds little beyond noting that the tool is Beta and makes a generic REST API call. It does not disclose authentication requirements, HTTP methods, side effects, rate limits, or response behavior, which is a major omission for an unrestricted Twilio API passthrough.

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 single sentence is front-loaded and efficient, but it is truncated and omits the details needed to understand the call format. Brevity is not the problem; incompleteness is.

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?

This is a generic REST passthrough with no annotations, no output schema, and an empty parameter schema. The description should explain method, endpoint, authentication, and payload handling; it provides only a high-level scope statement, leaving invocation guidance 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?

The input schema has zero parameters, so the baseline is 4. The description does not add parameter details, but there are no parameters to explain.

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

Purpose3/5

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

The description states a generic API passthrough and distinguishes it from the twilio_* siblings by reserving it for uncovered APIs. However, "Any call" is broad and the text is truncated, so it does not specify the request shape or exactly what the tool does beyond acting as an escape hatch.

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

Usage Guidelines4/5

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

It explicitly routes agents to use this only when the specific twilio_* tools do not cover the desired API, with Conversations and Studio as examples. The guidance lacks formal prerequisites or exclusions, but the gap-filling condition is clear.

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