Faxette

List blocked numbers

get_blocked_senders

Read-onlyIdempotent

Use this to see which fax numbers an organization has blocked. Faxes from them are deleted as they arrive. Returns 25 at a time, newest first. Pass next_page back as page for more. Needs the person to sign in to Faxette. It changes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "organization": "<organization>"
    },
    "name": "get_blocked_senders"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	The next_page from the previous call.
`organization`	Yes	The organization's id from get_organizations. Ask the person which one if there are several.

Output Schema

Name	Required	Description	Default
`next_page`	Yes	Pass it as page for the next 25. Null on the last page.
`blocked_senders`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

addedInput schema / properties / page

Added value: +{
+  "description": "The next_page from the previous call.",
+  "type": "string"
+}

addedOutput schema / properties / next_page

Added value: +{
+  "description": "Pass it as page for the next 25. Null on the last page.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "blocked_senders"
-]New value: +[
+  "blocked_senders",
+  "next_page"
+]

AddedNov 9, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses an auth requirement ('Needs the person to sign in to Faxette'), the operational consequence of a block (incoming faxes are deleted on arrival), page size and ordering ('Returns 25 at a time, newest first'), and confirms non-mutation. That is real behavioral context an agent cannot get from the 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?

Five short sentences, front-loaded with the purpose followed by consequence, pagination, auth, and safety. Nothing is redundant or buried.

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?

With an output schema present, return values need not be explained, and the description covers purpose, side effects, pagination, auth, and read-only nature. It is essentially complete for a two-parameter read tool, with only the absence of an explicit sibling alternative as a small gap.

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 100%, so the schema already documents both 'organization' and 'page' (including that page is the next_page from the previous call). The description's 'Pass next_page back as page for more' restates this, though the page-size and newest-first details add mild ordering context. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource: see which fax numbers an organization has blocked. It also adds the consequence ('Faxes from them are deleted as they arrive'), which disambiguates the resource semantically. It does not explicitly name the write-side sibling (block_sender/unblock_sender), so an agent must infer that this tool only reads.

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?

'Use this to see which fax numbers an organization has blocked' gives implied usage, and 'It changes nothing' signals this is the read path when a mutation is not wanted. However, there is no explicit when-not or named alternative for adding/removing blocks, so the agent has to infer the routing from sibling names alone.

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

All Faxette tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.