Marcora

find_app

Read-onlyIdempotent

Looks up the apps Marcora offers to connect (for example Gong or Fathom), by name or by what they do (for example "call recordings"). Call it BEFORE telling the user you can't reach an app or sending them to connect one: say only what it returns, and never claim an app is offered unless it appears in the result.

Each match carries the user's own connection_state (connected, not_connected, or expired: it worked before and needs renewing; a connection that was started but never completed reads as not_connected), whether add_context import_from can bring in its calls (brings_in_calls), and a connect_link. Offer the connect_link for an app that is not connected: it opens the Integrations page on that app, and nothing connects until the user acts. Once an app is connected, use its own tools in your session to find what you need.

Read-only: it changes nothing and makes no request to the app itself.

Links: present connect_link to the user exactly as returned. Never retype, shorten, or rebuild a link.

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": {
      "query": "<query>"
    },
    "name": "find_app"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Matches to return, 1 to 20. Default 10.
`query`	Yes	An app name or what it does. Required.

Output Schema

Name	Required	Description
`apps`	Yes	Matching apps, best match first. Empty when Marcora offers no such app.
`query`	Yes	The query that was searched.
`message`	Yes	How to use the result.
`total_matches`	Yes	How many apps matched before the limit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, and the description reinforces rather than contradicts them while adding genuinely new detail: the three connection_state values and what 'expired' means, the caveat that an abandoned connection reads as not_connected, and that nothing connects until the user acts on connect_link. It stops short of describing result ordering or pagination, so it is strong but not exhaustive.

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?

The hard directive ('call it BEFORE telling the user you can't reach an app') is front-loaded, followed by return-field semantics and then link-handling rules. The trailing Links block partly restates the earlier connect_link instruction, but the repetition targets a high-risk failure mode, so it is defensible rather than wasteful.

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?

An output schema exists, so return values need not be explained, yet the description still characterizes every meaningful field (connection_state, brings_in_calls, connect_link) so the agent knows how to act on a result. Given only two parameters and full schema coverage, nothing needed for correct invocation or follow-up behavior is missing.

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; the description earns above that by explaining that query accepts either an app name or a described capability, which is not evident from the schema's 'An app name or what it does.' The limit parameter is left entirely to the schema, which is acceptable given its self-documenting range and default.

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 and resource ('looks up the apps Marcora offers to connect') plus the two search modes ('by name or by what they do') with concrete examples (Gong, Fathom, 'call recordings'). An agent can tell this apart from connector-adjacent siblings like add_context because the description names the relationship explicitly.

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?

Gives an explicit when-to-use trigger: 'Call it BEFORE telling the user you can't reach an app or sending them to connect one.' It also states the handoff condition — once connected, use the app's own tools — and threads the link between this tool and add_context's import_from. Both the use case and the boundary are stated.

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

All Marcora 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.

Resources

Need Help?