MatchAwards

My matches

my_matches

Read-onlyIdempotent

Use this when the user asks for their own matches: open contracts for their business. It needs a linked MatchAwards account and uses that account's NAICS codes and state; without a linked account it asks the user to link one.

Options: type (federal or state), ignore_state (true: every state), only_my_set_aside (true: only notices set aside for the account's set-aside; by default open competitions are included too), limit (1 to 50, default 20). If has_more is true, call again with cursor=next_cursor and the same options.

Print each result's url, and sam_url for federal notices, as markdown links.

Do not use for searches with the user's own filters (search_contracts) or for grants (search_grants).

When you are done searching, call show_results once with the best ids; it shows them as a card the user can pick from.

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": "my_matches"
  }
}

Input Schema

Name	Required	Description
`type`	No	Narrow to federal or to state contracts. Leave empty for both.
`limit`	No	Number of results to return, 1 to 50.
`cursor`	No	next_cursor from the previous response. Pass it with the same filters to get the next page.
`ignore_state`	No	true: search every state, not only the profile's.
`only_my_set_aside`	No	true: only notices set aside for the profile's set-aside.

Output Schema

Name	Required	Description
`note`	No
`as_of`	No	When the API generated the results (ISO time).
`results`	Yes
`warning`	No	Set when paging stopped early; the results so far are still valid.
`has_more`	Yes	true: call again with cursor=next_cursor and the same filters.
`next_cursor`	No
`profile_used`	Yes
`settings_url`	No	Set when the profile has no NAICS codes: the match settings page on matchawards.com where the user adds them. Show it as a markdown link.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent safety profile, and the description adds materially more: the account-dependency and what happens without it, the pagination contract (if has_more is true, re-call with cursor=next_cursor and identical options), and required output formatting (url, plus sam_url for federal, as markdown links). It even prescribes the follow-up call to show_results with the best ids.

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 prerequisites, then options, output format, exclusions, and the follow-up step — a clean progression. Slight redundancy in restating limit's 1–50/default 20 range and ignore_state behavior that the schema already declares, which keeps it short of perfect.

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?

The tool is account-scoped, paginated, and feeds a two-step flow into show_results; the description covers all three plus the linking fallback. With an output schema present it correctly avoids describing return shapes and instead spends the space on rendering and chaining instructions.

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 still adds real semantics not present in the schema — notably that only_my_set_aside defaults to including open competitions, not just set-asides — and restates the pagination contract linking has_more/next_cursor to the cursor param.

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 — retrieving the user's own open contract matches for their business — and immediately scopes it to the MatchAwards account whose NAICS/state drive the results. Sibling differentiation is explicit: search_contracts for user-chosen filters, search_grants for grants.

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 the trigger condition ('when the user asks for their own matches'), the prerequisite (linked account, plus fallback behavior of asking the user to link one), and explicit exclusions naming the two alternative tools. Nothing about when to pick this tool is left to inference.

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

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