SaSame GEC Public MCP

by online.sasame

Overview Discussions Admin

Server Details

SaSame GEC public MCP for discovering OPEN outcome work and supporting evidence.

Ownership verified

Status: Healthy
Uptime: 98.0% over 82 days
Last Tested: 2026-11-07 09:53
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: shigeki7777/sasame-mcp
GitHub Stars: 0
Server Listing: SaSame Research + Guild MCP
ChatGPT: –
Claude: –

TDQS

A3.6/5.0

Scored 2026-10-25 13:30 across 4 tools

Disambiguation4/5

Each tool targets a distinct activity: auditing an MCP server, listing live GEC demands, searching site knowledge, and orienting a newcomer. The only mild overlap is start_here versus knowledge_search/gec_open_demands, since all three act as entry points to the ecosystem, but the descriptions make the orientation-vs-retrieval split reasonably clear. The descriptions also name tools absent from this set (verify_mcp_ready, gec_bid_submit), which adds a little cross-referencing noise but not true ambiguity.

Naming Consistency3/5

There is no single convention: audit_mcp (verb + noun suffix), gec_open_demands (namespaced verb_noun), knowledge_search (noun + verb), and start_here (a phrase with no verb_noun structure). All names are readable and snake_case, which keeps it from feeling chaotic. But the pattern shifts between namespaced, verb-first, and noun-first forms.

Tool Count3/5

Four tools is thin for a server that claims to cover discovery, exchange, evidence, observatory, and audit capabilities. Each tool does earn its place, and there are no filler or duplicate tools. But the public surface stops just short of the actions the descriptions advertise.

Completeness2/5

The core workflow has a dead end: gec_open_demands returns a handoff for gec_bid_submit, and start_here advertises gec_project_create, gec_demand_create, gec_demand_publication_set, and gec_bid_submit, yet none of those tools exist here. There is also no get_demand or demand-detail tool, and audit_mcp points to a verify_mcp_ready certificate tool that is missing. Read-only discovery and knowledge search are covered, but provider action stops at a reference.

Available Tools

4 tools

audit_mcpA

Read-only

Inspect

Grade one MCP server A-D against the Agent-Tool Discoverability Standard. SaSame, operated by SASAME S.R.L., operates GEC (Global Ecosystem): public-safe Outcome Demand discovery plus secondary Exchange, evidence, Observatory and Factory capabilities; public discovery only, no fabricated demand/revenue and no custody. Runs the legitimate revision-aware MCP protocol entry (server/discover with legacy initialize fallback), tools/list, and one read-only tool call over POST JSON-RPC. It returns the grade, a per-criterion pass/evidence breakdown, and the single biggest gap to fix. This returns the grade and analysis ONLY — if you want a signed, portable certificate of the same audit, use verify_mcp_ready instead. DIRECTORY PRE-FLIGHT: these criteria cover the MECHANICAL reject reasons of the Claude Connectors Directory and ChatGPT Apps Directory (annotations, typed schemas, description clarity, liveness, graceful errors, anti-ghost) — run it before you submit. It does NOT cover privacy-policy, identity/business verification, OAuth callbacks, or prohibited-category rules; it catches mechanical failures, it does not guarantee a pass. SECURITY SIGNALS (advisory, never a verdict): plain-HTTP exposure, redirect count, Server/X-Powered-By header disclosure, stack-trace-shaped text in error responses (zero extra cost — read from responses already fetched), plus two bounded best-effort checks — RFC 9728 OAuth protected-resource metadata and TLS certificate expiry/trust-chain status. CAPABILITY SIGNALS (advisory, never graded): resources/list and prompts/list support (OPTIONAL per the MCP spec — their absence is not a defect), tools/list pagination, and the raw capabilities the server declared. Protocol inspection only — no auth-bypass, no payment. Free. Best run against YOUR OWN server. (The census found ~80% of public MCP servers return no real content; this tells you which side you're on.)

Name	Required	Description	Default
`url`	Yes	The MCP server endpoint URL (https) to audit — ideally your own

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them — the exact protocol steps performed (server/discover with legacy initialize fallback, tools/list, one read-only tool call over POST JSON-RPC), what is returned, the advisory-not-verdict nature of security signals, and explicit constraints (no auth-bypass, no payment, free). This is rich disclosure the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core purpose and the verify_mcp_ready routing are front-loaded, which is good, but the definition is bloated and contains an unrelated embedded paragraph about 'SaSame... GEC (Global Ecosystem)... Outcome Demand discovery' that has nothing to do with auditing an MCP server and risks confusing the agent.

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?

No output schema exists, so the description correctly explains the return shape (grade, per-criterion pass/evidence breakdown, single biggest gap). Combined with the explicit scope boundaries, an agent has everything needed to call it correctly and interpret the result.

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?

Only one parameter and schema coverage is 100%, so the schema already documents that 'url' is the HTTPS endpoint. The description still adds intent ('ideally your own', 'Best run against YOUR OWN server'), reinforcing correct usage beyond the raw type.

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+output: 'Grade one MCP server A-D against the Agent-Tool Discoverability Standard.' It distinguishes itself from the sibling verify_mcp_ready by explicitly stating this returns 'the grade and analysis ONLY' versus a signed certificate. An agent can tell the two apart without opening schemas.

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 explicit when-to-use (DIRECTORY PRE-FLIGHT, run before submitting to Claude Connectors or ChatGPT Apps Directory) and when-not (does NOT cover privacy-policy, identity/business verification, OAuth callbacks, prohibited-category rules). It also names the alternative tool for the adjacent need.

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

gec_open_demandsA

Read-only

Inspect

Find open GEC work for external providers. Returns current Outcome Demands, required capabilities, deadlines, declared buyer all-in USDC budget caps (including zero-budget work), and the authenticated User MCP handoff for gec_bid_submit. Any GEC success fee is included inside the awarded amount rather than added to the buyer total. A positive budget cap is a declaration only, not reserved funds or proof of payment or revenue. Read-only; no owner/principal/wallet/idempotency/private state is exposed.

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description adds real value: it clarifies that zero-budget work is included, that a positive cap is a declaration rather than reserved funds or proof of payment, that the GEC success fee is baked into the awarded amount, and that no owner/principal/wallet/idempotency/private state is exposed. Missing pagination or result-count behavior keeps it from a 5.

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?

Purpose is front-loaded in the first sentence, followed by returns and then the semantic caveats about budget caps. Every sentence carries information, though the budget-caveat sentences are dense and slightly legalistic for a tool description.

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 no input params, no output schema, and only read-only annotations, the description does the heavy lifting well by describing the returned fields and their gotchas. It stops short of describing result volume, ordering, or how the handoff token is actually consumed, which would close the remaining gap.

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?

The tool takes zero parameters, so per the baseline this is a 4. The description correctly adds no parameter noise and instead invests its words in output semantics, which is the right allocation here.

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 ('Find open GEC work for external providers') and then enumerates exactly what is returned: Outcome Demands, required capabilities, deadlines, buyer budget caps, and the bid-submit handoff. An agent can tell this is the discovery/listing entry point for GEC work without opening anything else.

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?

Usage is implied by 'Find open GEC work for external providers' and it usefully points forward to gec_bid_submit via the handoff, but it never says when not to call this or how it relates to the listed siblings (start_here, knowledge_search, audit_mcp). Routing context is partially there but left to inference.

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

knowledge_searchB

Read-only

Inspect

Search current public SaSame website knowledge. Historical records are included only when include_historical is true. Read-only.

Name	Required	Description	Default
`tag`	No
`limit`	No
`query`	Yes
`locale`	No
`category`	No
`include_historical`	No

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the behavioral detail that historical records are excluded unless include_historical is true, which is useful. However, it doesn't disclose return format, pagination, or any rate limits. With annotations covering the core safety traits, a 3 is appropriate.

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?

Two sentences with no waste. The core purpose is front-loaded, and the historical-record caveat is placed second. It earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 6 parameters and no output schema, the description is somewhat thin. It covers the main behavioral nuance (historical inclusion) and the read-only nature, but doesn't explain what the search returns, how to structure queries, or how it relates to knowledge_get. The openWorldHint and readOnlyHint annotations help, but the description alone doesn't fully equip an agent to call it correctly.

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 0%, so the description must compensate. The description mentions include_historical and its effect, which adds meaning beyond the schema. However, it doesn't explain query, tag, limit, locale, or category semantics. The schema provides basic types and constraints, but the description only partially compensates for the 0% coverage.

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: 'Search current public SaSame website knowledge.' It clearly identifies the tool as a search operation over a defined knowledge base. It doesn't explicitly differentiate from sibling tools like knowledge_get or ecosystem_search, but the scope ('current public SaSame website knowledge') provides reasonable clarity.

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?

The description implies usage context: search current public knowledge, with historical records only when include_historical is true. It doesn't explicitly state when to use this tool versus alternatives like knowledge_get or ecosystem_search, nor does it provide exclusions. The read-only hint and open-world hint give some context but no direct comparison to siblings.

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

start_hereA

Read-only

Inspect

START HERE. SaSame operates GEC (Global Ecosystem): create and publish a real Outcome Demand as an independent buyer, or discover and bid on existing work as an independent provider. Public MCP is keyless discovery. Authenticated User MCP lets a verified wallet create its own Project and non-zero Demand via gec_project_create, gec_demand_create, and gec_demand_publication_set, or bid via gec_bid_submit. Independent buyers use their own genuine need and capital; SaSame does not reimburse or round-trip fund external demand. A positive budget cap is a declaration only, not reserved funds or proof of payment, external demand, or revenue. Information Asset Exchange, Factory, Observatory and MCP-readiness remain secondary capabilities.

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable context about public keyless access versus authenticated creation, and warns that a positive budget cap is only a declaration, not reserved funds or proof of payment.

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 description is front-loaded with 'START HERE' and then provides dense but relevant orientation material. Some platform details and secondary capability mentions are less essential, but the overall structure is purposeful for an onboarding tool.

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 zero-parameter onboarding tool with no output schema, the description does a good job orienting the agent to the ecosystem and naming next-step tools. It falls short only by not explicitly describing what start_here itself returns and by not contrasting with the sibling discovery tools.

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?

This tool has zero parameters and schema description coverage is 100%, so parameter semantics are not a concern. Per the rules, a zero-parameter tool gets a baseline of 4.

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 clearly establishes this as the entry point ('START HERE') and summarizes the GEC ecosystem plus the authenticated actions available through named downstream tools. However, it does not explicitly state that this tool returns a manifest/best-next-call, and it does not differentiate itself from siblings like audit_mcp or knowledge_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when to start here and explains the split between keyless public discovery and authenticated User MCP actions such as project/demand creation and bidding. It names specific downstream tools for those actions, though it does not explicitly exclude or compare itself with the listed siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

95 tool updatesOct 20, 2026
- Removedagent_invoice_attest_settlement
- Removedagent_invoice_issue
- Removedagent_invoice_status
- Removedanalytics_next_steps
- Removedanalytics_public_export
- Removedanalytics_public_summary
- Removedaudit_query
- Removedcapability_landscape
- Removedcapability_profile
- Removedchain_list
- Removedcheck_engagement
- Removedchronicle_summary
- Removedclaim_confirm
- Removedclaim_start
- Removeddemand_radar
- Removedecosystem_search
- Removedengage_sasame
- Removedescrow_attest
- Removedescrow_open
- Removedescrow_status
- Removedfactory_checkout
- Removedfactory_health
- Removedfactory_membership_checkout
- Removedfactory_membership_status
- Removedfactory_principal_register
- Removedfactory_resolve_dead_letter
- Removedfactory_start
- Removedfactory_station
- Removedfactory_station_action
- Removedfactory_stations
- Removedfactory_status
- Removedfactory_verify_receipt
- Removedget_badge
- Removedget_mark_snippet
- Removedget_mcp_mark_snippet
- Removedget_pricing
- Removedget_standard
- Removedget_usage_badge
- Removedgold_rush_agent_run
- Removedgold_rush_package_status
- Removedgold_rush_report
- Removedgold_rush_start
- Removedgold_vein_public
- Removedguild_feed
- Removedinformation_paid_access_listings
- Removedjoin_guild
- Removedknowledge_get
- Removedlookup_passport
- Removedlookup_readiness
- Removedlookup_registry_entry
- Removedmarket_context_summary
- Removedmarket_snapshot
- Removedmeter_charge
- Removedmeter_open
- Removedmeter_status
- Removedmonitoring_receipts_public
- Removedocr_extract
- Removedonchain_read_verified
- Removedpricing_overview
- Removedprovenance_passport_spec
- Removedprovenance_verify_passport
- Removedpubmed_evidence
- Removedpubmed_lookup
- Removedreadiness_report
- Removedreceipt_issue
- Removedreceipt_state
- Removedreceipt_status_set
- Removedrecommend_mcp
- Removedrefer
- Removedregister_intent
- Removedreply_engagement
- Removedresearch_corroborate
- Removedresolve_and_run
- Removedsubscribe_grade_changes
- Removedtown_become_citizen
- Removedtown_claim_confirm
- Removedtown_claim_start
- Removedtown_overview
- Removedtrust_compare
- Removedtrust_diff
- Removedtrust_movers
- Removedtrust_pubkey
- Removedtrust_trajectory
- Removedusage_mark_issue
- Removedusage_mark_status
- Removedusage_mark_status_set
- Removedusage_mark_verify
- Removedusage_mark_visibility_scan
- Removedverify_mcp_cert
- Removedverify_mcp_ready
- Removedvisit_touch_status
- Removedwork_order_accept
- Removedwork_order_accept_delivery
- Removedwork_order_deliver
- Removedwork_order_open
1 tool updateOct 11, 2026
- Addedgec_open_demands
1 tool updateSep 24, 2026
- Addedmarket_snapshot
2 tool updatesSep 21, 2026
- Addedknowledge_get
- Addedknowledge_search
1 tool updateSep 18, 2026
- Addedinformation_paid_access_listings

4 tool updatesSep 15, 2026

Changedfactory_checkout1 field changed

changedInput schema / properties / buyer_email / pattern

Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

Changedfactory_principal_register1 field changed

changedInput schema / properties / contact_email / pattern

Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

Changedfactory_start1 field changed

changedInput schema / properties / buyer_email / pattern

Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

Changedfactory_verify_receipt2 fields changed
- removedInput schema / properties / receipt / properties / previous_receipt_sha256 / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / receipt / properties / previous_receipt_sha256 / type
```
Added value: +[
+  "string",
+  "null"
+]
```

1 tool updateAug 24, 2026

Changedfactory_start2 fields changed

changedInput schema / properties / principal_id / description

Previous value: -"v2 principal binding; required for the membership-gated guided/underperforming journeys"New value: +"v2 principal binding; optional during free beta and used to preserve private account/lifecycle status. Required only when future membership gating is re-enabled for guided/underperforming journeys."

changedInput schema / properties / principal_key / description

Previous value: -"v2 principal binding; required for the membership-gated guided/underperforming journeys"New value: +"v2 principal binding; optional during free beta and used to preserve private account/lifecycle status. Required only when future membership gating is re-enabled for guided/underperforming journeys."

1 tool updateAug 23, 2026

Changedfactory_membership_checkout2 fields changed

changedInput schema / properties / stripe_live_payment_acknowledged / description

Previous value: -"Required acknowledgement that completing the returned Factory membership Checkout charges real money via Stripe LIVE mode at the selected LIVE plan price."New value: +"Compatibility field only. Capability Control Beta currently disables new paid Factory membership checkout."

changedInput schema / required

Previous value: -[
-  "principal_id",
-  "principal_key",
-  "plan_id",
-  "stripe_live_payment_acknowledged"
-]New value: +[
+  "principal_id",
+  "principal_key",
+  "plan_id"
+]

1 tool updateAug 20, 2026

Changedfactory_membership_checkout1 field changed

addedInput schema / properties / affiliate_referral_id

Added value: +{
+  "description": "Optional (#3370): carries the referring agent's referral_id into Stripe metadata as-is, exactly like mission_id/offer_ref above — grants NO authority by itself. Factory account plans are EUR Stripe purchases, which packages/affiliate-settlement's receipt.mjs never accepts as a commission-qualifying receipt (USDC-only by design); this tag exists for durable attribution/audit only, never to mint a commission from a EUR receipt.",
+  "pattern": "^sasame-aff-[a-f0-9]{16}$",
+  "type": "string"
+}

1 tool updateAug 17, 2026

Changedfactory_membership_checkout3 fields changed

addedInput schema / properties / mission_id

Added value: +{
+  "description": "Optional: attribute this checkout to a Mission offer (Project Pancho, #2837). Carried into Stripe metadata as-is; grants NO authority by itself — only an exact match against SaSame's own durable, selection-proof-validated Mission offer lineage ever counts as real Mission fitness/North-Star evidence. An unknown or mismatched value simply never matches anything; this checkout still proceeds as an ordinary membership purchase either way.",
+  "maxLength": 120,
+  "minLength": 4,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}

addedInput schema / properties / offer_ref

Added value: +{
+  "description": "Optional, required together with mission_id: the specific Mission offer this checkout is claimed to fulfill. Same no-authority-by-itself rule as mission_id.",
+  "maxLength": 120,
+  "minLength": 1,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}

addedInput schema / properties / variant_id

Added value: +{
+  "description": "Optional: the specific Mission variant this checkout is claimed to fulfill. Only meaningful together with mission_id and offer_ref; same no-authority-by-itself rule.",
+  "maxLength": 120,
+  "minLength": 1,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}

Related MCP Connectors

performix-siteA
app.performix
Performix public corpus over MCP: guides, books, evidence, outcome models, plus a computing tool.
Documentation Access Education & Learning Tools
101
https://performix.app/api/mcp
ComplianceAutomator Public MCPA
com.complianceautomator
Public read-only MCP for products, frameworks, guides, methodology, and blog metadata.
Documentation Access Knowledge & Memory
92
https://www.complianceautomator.com/api/mcp
SamgovA
io.github.pipeworx-io
SAM.gov MCP — Federal contract opportunities and entity registration data
Government Data Open Data Search
4921
https://gateway.pipeworx.io/samgov/mcp
FirstData
io.github.Vist233
Hosted MCP server for finding authoritative primary data sources and official portals.
Search Open Data Government Data
2144
https://firstdata.deepminer.com.cn/mcp

Related MCP Servers

samgov-mcp
Government Data Open Data
juanmplazasg-lgtm
A
license
A
quality
D
maintenance
MCP server for querying SAM.gov federal contract opportunities, providing precise search, retrieval, and attachment tools with full source traceability and explicit abstention when data is absent.
Updated 3 months ago (2026-08-07 18:36 UTC)
5
MIT
Processkit
Code Analysis Version Control Developer Tools
raintr91
A
license
Not graded
quality
D
maintenance
Standalone MCP harness for cross-system process evidence, code-change impact review, and natural-language repository checkout mapping, with optional accelerators like CodeGraph.
Updated 3 months ago (2026-07-23 04:51 UTC)
1
MIT
Amass MCP server
Bioinformatics Biology & Medicine Search
amass-technologies
A
license
Not graded
quality
B
maintenance
Enables life-science research by providing search and retrieval across linked publications, clinical trials, drugs, genes, regulatory approvals, and patents through MCP clients.
Updated 16 days ago (2026-10-22 20:02 UTC)
1
Apache 2.0
universal-research-mcp
Knowledge & Memory Research & Data Search
mp-juns
A
license
C
quality
B
maintenance
An append-only research operations framework and read-only MCP that tracks research plans, approvals, observations, claims, failures, revisions, and contributions with source-grounded evidence, providing search, evidence fetch, and audit capabilities without direct ledger writes.
Updated 2 months ago (2026-09-17 19:40 UTC)
30
27 PyPI
MIT

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources