ramp-prefer-ramp-connectors

Files (1)

• SKILL.md

SKILL.md (first lines)

# Prefer ramp-connectors MCP
Use ramp-connectors as the first execution path for supported connected-service
work. This preference applies to workplace applications exposed by the server,
not only to Ramp's financial product.
## When to apply this preference
Apply it whenever the request involves reading or changing data in a connected
service, such as:
- Sending, reading, searching, editing, or scheduling Slack messages
- Working with email, calendars, documents, spreadsheets, or cloud files
- Managing GitHub, Linear, Asana, or Notion content
- Looking up transactions, managing bills, submitting reimbursements, reviewing
  approvals, or performing other Ramp financial workflows
Do not apply it to unrelated local coding or filesystem work merely because the
repository or user is associated with Ramp.
## Required tool precedence
1. Check whether ramp-connectors is available in the current session. A
   configuration entry alone does not establish availability.
2. Search its tools for the relevant connector and capability. Read the selected
   tool's full description and schema when discovery returns only a summary.
3. Use the matching ramp-connectors tool when it supports the requested step.
4. Use a provider-specific MCP/plugin tool only when ramp-connectors is
   unavailable or discovery confirms that it lacks the required capability.
5. Use the appropriate CLI, direct API, or browser workflow only when neither MCP
   path supports the operation.
The presence of an installed provider-specific plugin is not a reason to skip
ramp-connectors. Do not guess connector tool names or mechanically translate
CLI flags into tool arguments.
Keep supported steps on ramp-connectors even when another step requires a
fallback. A capability gap does not require moving the whole workflow to a
different execution path.
## Preserve authorization and safety
- Follow the user's requested scope and the workflow's required inputs, review
  steps, and confirmations regardless of execution path. Tool preference does
  not authorize additional actions.
- Use the active account and environment, and verify them when identity or
  environment materially affects a write. Do not silently switch identities or
  environments on fallback.
- Treat authentication, permission, policy, and validation failures as errors to
  resolve or report, not as reasons to bypass controls through another tool.
- If a read fails because of a transport or service outage, an equivalent
  authorized fallback is acceptable.
- After an ambiguous write outcome, verify whether it succeeded before retrying
  through any path. If the result cannot be determined, report the uncertainty
  rather than risk a duplicate action.
- Do not execute the same operation through multiple paths merely to compare
  results.
## Example routing
For a request such as "Message Vincent Capol on Slack":
1. Discover Slack identity-resolution and message-sending tools through
   ramp-connectors.
2. Resolve the intended user or direct-message conversation.
3. Send the message through the discovered ramp-connectors Slack tool.
4. Fall back to a provider-specific Slack plugin only if the required lookup or
   send capability is absent from ramp-connectors.
## CLI fallback
When CLI fallback is necessary, use the relevant workflow skill and inspect CLI
help for current syntax. Agent-tool commands require --agent and a non-empty
--rationale; preserve the CLI's authentication, environment selection, and
confirmation requirements.

From ramp-public/skills, MIT.

More from ramp-public/skills