Servidor MCP de Forcefield Silicon

• Nombre en el registrocom.forcefieldsilicon/mdengineverificado en el registro MCP

El nombre en el registro está bajo forcefieldsilicon.com. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-24
• Herramientas14
• El servidor se llamacom.forcefieldsilicon/mdengine
• Versión del servidor0.10.0
• Versión del protocolo2025-06-18

El 2026-10-24 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 543 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 4 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 4 hasta ahora
• Respondiómidiendo4 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta559 ms
• Espacio en el contexto del agente≈ 2383 tokenslas definiciones de todas sus herramientas (14), que el agente lleva en cada turno
• Definiciones de herramientasA · 100 de 100
• Resultados tipados0 de 14 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Todas las herramientas pasan las seis comprobaciones.

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• guide

  No key needed. Without customer_type: the list of guides (one line each), the start page and how to get a key. With customer_type (mineral-processing | dark-proteins): the full guide, which says what to supply, what runs, what comes back…

• campaign_request

  No key needed. Sends a study request to a person and returns a request_id, the tier that fits, the price band, what we still need from you, the next step and the claim scope. Nothing is run or charged. Call it after reading a guide.

• account

  Balance in USD (`balance_usd`), the part of it held by your unfinished jobs (`reserved_usd`, `held_jobs`) and what a new submit can use (`available_usd` = balance - reserved; a submit needs wall_limit_s x rate of it), how jobs are priced…

• submit_job

  One call: create a hosted GPU job, upload the deck given INLINE as {relative_path: text}, and queue it. Total inline size <= 8 MB; for larger decks use create_job, PUT the tarball to upload_url, then start_job. Billing starts at the first…

• create_job

  Step 1 of the two-step path for big decks: validates the spec, reserves a job id, returns a presigned upload_url. PUT the deck as a .tar.gz (<= 2 GB, relative paths, input at `input`) to upload_url, then call start_job.

• start_job

  Step 2: queue a job whose deck tarball has been uploaded. A GPU pod is launched; billing starts when it reports running.

• job_status

  State (created|uploaded|queued|launching|running|uploading|done|failed|cancelled), GPU, rate, billed seconds, cost so far, exit code, error, last thermo lines, and the post-run verdict: clean | warnings (a done run whose log shows QEq CG…

• job_log

  The last <= 20 thermo/log lines the running pod reported (30 s heartbeat). Full log.lammps is in the results tarball.

• job_results

  For a done/failed job: a presigned download_url (valid ~7 days) for the results tarball (work/, log.lammps, exitcode). Results are deleted 30 days after the run.

• list_jobs

  Jobs of this API key, newest first. Compact rows (id, state, label, created, finished, gpu, cost_usd, error) unless full=true.

• delete_results

  For a finished job: delete its deck and results tarballs immediately instead of at the automatic 30-day purge. Metadata and billing records are kept; results can no longer be downloaded.

• capabilities

  Capability manifest of the hosted runners: LAMMPS version, installed packages, and every style by category with gpu=true (KOKKOS-accelerated) or gpu=false (exists, but runs on the pod's CPU cores at the GPU rate). Default = compact…

• preflight_deck

  Dry run of the check submit_job performs: which styles the deck asks for are MISSING on every hosted LAMMPS image (the run would exit at startup), which are CPU-only, whether its pair style will use the GPU at all, and which image…

• cancel_job

  Cancel a job that is not finished. A running job is billed up to the cancel time; its pod is terminated.