Skip to main content
Glama
Sign In

SkipCalls

by com.skipcalls
OverviewDiscussionsAdmin

search

Read-only

Targeted search across calls, contacts, SMS, or knowledge. Choose the narrowest scope. For calls/contacts/SMS use only a phone number, name, company, or 1-4 distinctive words, never a full request. Any explicit call time window takes precedence over a name, phone, company, or topic: use getCallHistory.sinceHours and do not call search in the same turn to bypass or widen that window. Natural-language questions are allowed only with scope=knowledge. scope=all searches contacts, calls, and SMS but not knowledge. On follow-ups, reuse sufficient prior results instead of repeating the same query with a higher limit. Returns Call IDs for getCallDetails.

Input Schema

NameRequiredDescriptionDefault
limitYesMaximum results per selected section. Choose the smallest useful limit; normally 3, or omit for the default 5. Use more only when the user asks for a broader list. Up to 10; larger values are capped to 10.
queryYesThe shortest distinctive lookup text. For calls, contacts, or text conversations use only a phone number, email, name, company, or 1-4 meaningful topic/message words. Never restate the full user request. Any explicit call time window such as "today" or "a couple hours ago" takes precedence over a name, phone, company, or topic: use getCallHistory.sinceHours and do not use search to bypass that window in the same turn. A natural-language question is allowed only with scope="knowledge".
scopeYesRequired search surface: calls, contacts, conversations, knowledge, or all. conversations searches SMS, email, and website-chat threads. Pick the narrowest surface. all searches contacts, calls, and text conversations but not knowledge; use it only when the user explicitly asks across multiple operational data types.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds non-obvious behavior: the precedence rule where a time window overrides entity/topic matching, the exclusion of knowledge from scope=all, and the fact that results are Call IDs intended for getCallDetails. It does not describe result shape for the contacts/conversations/knowledge sections.

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?

Front-loaded with purpose then routing constraints, and every sentence carries an actionable rule. The main inefficiency is that the time-window precedence rule is stated twice (in the description and again in the query parameter), which is redundant rather than harmful.

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?

For a 3-parameter, fully-required search with no output schema, the description covers routing, query shaping, precedence, and follow-up behavior — everything needed to call it correctly. The one remaining gap is what the non-call sections return, since only 'Call IDs for getCallDetails' is mentioned.

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% and the description's parameter guidance (shortest distinctive query, narrowest scope, small limit) largely restates what the schema properties already say verbatim. It adds no syntax, format, or edge-case detail beyond the structured fields, so the baseline 3 applies.

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?

Opens with a specific verb+resource ('Targeted search across calls, contacts, SMS, or knowledge') and enumerates the surfaces, so an agent can distinguish it from getCallHistory, search_mentions, or searchHelpCenter without opening the schema. The routing sentence about scope=all excluding knowledge further sharpens the boundary.

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 names the alternative and the condition that selects it: an explicit call time window must go to getCallHistory.sinceHours and search must not be called in the same turn to widen it. It also constrains query form ('1-4 distinctive words, never a full request'), restricts natural-language questions to scope=knowledge, and tells the agent to reuse prior results on follow-ups rather than re-querying with a higher limit.

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

All SkipCalls toolsInspect
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.

Resources